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FOREWORD 


approve  2:hls  revised  "Guide  on  Design  to  Cost"  for  use  within  Oul 
:Tiands.  It  provides  Information  and  guidance  for  application  of  the 
Design  to  Cost  concept. 

Since  the  first  edition  of  this  Guide  In  October  1973i  theie  have  been 
numerous  applications  of  Design  to  Cost  in  both  major  and  non-major 
system,  sub-system  and  con^onent  developments.  The  great  majority  of 
these  applications  have  been  limited  to  "unit  production  cost".  Al- 
though no  Design  to  Cost  program  has  yet  matured  to  the  point  at  which 
"lessons  learned"  can  be  garnered  from  factual  cost  data,  we  are  con- 
vinced from  evidence  in  hand  that  the  concept  works  and  will  be  of 
great  benefit. 

However,  the  concept  can  and  must  be  expanded  beyond  unit  production 
cost  to  include  operating  and  support  costs,  ^preaches  which,  concen- 
trate on  those  operating  and  suppoi't  costs  which  are  design  sensitive 
are  currently  available  even  In  the  absence  of  a uniform,  useable  and 
historical  data  base  for  all  operating  and  support  costs. 

We  seek  a favorable  balance  among  the  elements  of  life  cycle  cost, 
(development  production,  operating  and  support  costs)  and  the  perform- 
ance of  every  system. 

There  are  no  easy  steps  in  designing  a complex  weapon  system  to  estab- 
lished cost  goals.  The  DOD  and  contractors  must  be  committed,  effec- 
tively communicate  and  maintain  essential  effort  toward  achieving  the 
established  Design  to  Cost  goals. 

Supplemental  instructions  may  be  lssuei}..l>w  the  Individual  commands. 
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MHMORANDUM  FOR  SECRETARIES  OF  THE  MILITARY  DEPARTMENTS 
SUBJECT:  Joint  Logistics  Commanders  Guide  on  Design  to  Cost 


I am  in  receipt  of  a copy  of  the  Joint  Logistics  Commanders 
Guide  on  Design  to  Cost  which  was  approved  by  the  Commanders 
on  9 January  1976  and  revises  the  original  Guide  issued 
3 October  1973, 

The  revised  Guide  has  been  reviewed  by  cognizant  members  of 
my  staff  and  found  to  provide  an  excellent  expansion  of  the 
conceptual  approaches  to  the  application  of  the  Design  to 
Cost  concept.  It  is  consistent  Tvith  existing  DoD  policy 
and  is  recommended  for  use  on  both  major  and  less  than  major 
defense  systems  acquisition  programs  throughout  the  Depart- 
ment of  Defense.  Instructions  as  necessary  should  be  issued 
by  individual  components'  to  provide  detailed  guidance  on  tbfi 
pecularities  of  Service  implementation  of  the  Design  to  Cost 
concept.  These  instructions  should  supplement  the  Joint 
Guide  and  be  subordinate  to  the  information  contained  therein. 

The  first  tentative  step  toward  requiring  the  use  of  life 
cycle  cost  elements  as  design  parameters  is  in  consonance 
with  our  ultimate  objective  of  Design  to  Life  Cycle  Cost. 
Continued  care  must  be  exercised,  however,  to  insure  that  a 
balanced  approach  consistent  with, our  technical  knowledge, 
data  base,  and  contracting  abilities  is  maintained. 

I request  that  the  Guide  continue  to  be  updated  to  reflect 
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INTRODUCTION 


1.1  PURPOSE  OF  THE  GUIDEivThe  Design  to  Cost  (DTC)  concept  estrb. 
lishes  life  cycle  cost  (life  cycle  cost  to  the  ntsxinum  extent  fee- 
sible)  as  a design  parameter  during  a system's  design  and  develop- 
ment 'phase  and  provides  a cost  discipline  to  be  used  throughout  the 
acquisition  of  a system. 

This  Guide  provides  information  and  guidance  for  application 
of  the  Design  to  Cost  concepts  contained  in  DOD  Directive  '5000.28, 
Design  to  Cost,  dated  23  May  1975  which  has  been  Included  as  Appen- 
dix A.  The  ef'^ectlveness  of  Design  to  Cost  in  meeting  weapon  sys- 
tems needs  within  budget  constraints  greatly  depends  upon  the  man- 
ner in  which  it  is  in^lemented.  This  Guide  makes  no  attenq)t  to 
develop  a standardized  approach  to  implement  Design  to  Cost  other 
than  to  outline  certain  policies  and  basic  guidelines.  Design  to 
Cost  must  be  tailored  to  fit  the  individual  program  based  on  stated 
objectives  and  risks  involved, A 

The  Guide  expounds  upon  the  following  questions  on  Design  to 
Cost:  Why  Design  to  Cost?  What  is  it?  To  which  programs  should 
Design  to  Cost  be  applied  and  when?  Further,  it  also  provides  guid- 
ance for  a Design  to  Cost  effort  and  describes  what  Design  to  Cost 
goals  should  be  established,  incorporated  into  contracts,  managed 
and  tracked. 

1.2  BACKGROUIO} 


Projected  defense  budget  levels  and  rising  costs  of  acquiring, 
operating  and  supporting  defense  systems  and  equipment  have  created 
the  need  to  make  cost  a principal  design  parameter. 


Several  cost  effective  weapon  systems  have  recently  been  devel- 
oped which,  because  of  their  cost,  were  not  affordable  in  adequate 
numhers  to  satisfy  mlssion  requirements,  necessitating  additional 
lower  coat  developments. 

Design  to  Cost  is  not  a new  concept.  It  hss  been  used  success- 
fully by  many  asnufacturets  of  commercial  products.  DOD  has  initi- 
ated a number  of  specific  design  to  cost  development  programs  from 
which  we  are  leamlns  how  to  structure  and  manage  such  efforts. 

Emphasis  in  the  past  has  been  placed  primarily  on  "unit  produc- 
tion coat"  with  "consideration"  of  life  cycle  cost  impacts.  The 
reason  was  the  Inability  to  predict,  or  in  fact  measure,  total  op- 
erating and  support  costs.  This  has  provided  little  motivation  to 
the  responsible  Program  Manager  and  subsequently  to  tns  development 
contractors  to  trade-off  lower  predicted  savings  In  operating  and 
support  cost  in  the  future  for  near  term  "known"  higher  unit  produc- 
tion cost. 

Recent  acquisition  strategies,  however,  have  made  inroads  to 
addressing  the  operating  and  support  cost  portion  of  life  cycle  cost. 
The  approach  has  been  to  look  at  that  portion  of  the  operating  and 
stipport  costs  fdtlch  are  design  dependent,  reesonably  predictable, 
and  verifiable  during  the  initial  period  of  system  operation.  While 
only  a part  of  the  total  operating  and  support  cost  meets  this  cri- 
teria it  is  the  most  important  part  - the  part  that  the  DOD  Program 
Manager  and  the  contractors  can  effect  and  control  during  the  acqui- 
sition cycle. 


2 


1.3  CONCEPT 


The  concept  of  Design  to  Cost  Is  basically  a slinple  one.  Cost 
is  established  as  a design  parameter  In  the  same  sense  and  for  the 
same  purpose  as  performance  parameters  such  as  speed,  range  and  kill 
probability  and  schedule  parameters  such  as  initial  operational 
pablllty.  (The  word  cost,  when  used  alone  In  the  guide  and  in  POD 
Dir  5000.28,  means  the  sum  of  development,  production,  operating 
and  support  costs.) 

Every  system  has  many  parameters  which  must  be  considered  In 
design.  Life  Cycle  Cost  has  now  been  added.  Because  of  this  mul- 
tiplicity of  considerations,  there  are  a great  number  of  possible 
cond}lnaclon3  of  values  for  each.  At  the  outset  of  an  acquisition, 
the  optimum  combination  cannot  be  identified.  However,  certain 
limits  must  be  identified.  Given  a threat  environment,  level  of 
technology  and  mission  scenario,  there  are  dictated  certain  minimum 
essential  performance  parameters,  the  values  of  ^rttich  must  be  at- 
tained or  the  system  Is  not  mission  capable.  There  also  results  a 
certain  cost  which  laust  be  achieved  or  bettered  or  the  system  is 
not  affordable.  The  solution  can  be  visualized  as  follows t 

COST  CEILING 

RANGE  OF  ACCEPTABLE  SOLUTIONS 
PERFORMANCE /FLOOR 

These  limits  fix  the  area  In  which  the  optimum  combination  of 
performance,  cost,  and  schedule  values  must  fall.  In  this  area,  it 
may  be  found  that  performance  and  schedule  values  above  the  mlnitnum 
established  requirement  are  useful  and  can  be  obtained  wltbln  the 
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affordable  coat.  Performance  and  schedule  values  above  inlninuk&  will 
also  be  found  for  which  the  added  cost,  although  within  the  limits 
of  affordability,  are  unjustifiable  In  view  of  the  utility  of  the 
added  performance. 

Herein  can  be  defined  the  basic  difference  between  "cost  effec- 
tiveness" and  '•Design  to  Cost."  There  can  be  many  solutions  above 
the  performance  floor  and  even  above  the  cost  ceiling  which  can  be 
justified  as  being  cost  effective.  In  today's  dynamic  environment, 
the  "optlfflum  cost  effective  solutions"  may  result  in  designs  which 
are  above  an  affordable  cost  ceiling.  The  Design  to  Cost  process 
has  therefore  been  introduced  to  identify  the  optimum  cost  effec- 
tive solution  within  the  above  limits,  and  develop  a design  which 
can  be  successfully  produced  to  the  established  cost  goal. 

Whenever  feasible,  Design  to  Cost  goals  should  be  established 
for  all  elements  of  future  Life  Cycle  Cost  which  are  design  con- 
trollable. Acquisition  strategies  must  then  be  structured  to  a- 
chieve  these  goals.  Where  appropriate,  contractual  comuitmeuts 
should  be  used  to  hold  the  contractors  to  cost  goals  that  are  con- 
sistent with  the  total  system  DTC  goal.  An  acquisition  strategy 
tailored  to  achieve  DTC  goals  and  a compatible  contractual  stinic- 
ture  and  tracking  system  plus  c clear  line  of  communication  and 
understanding  between  the  PM  and  the  contractor  are  the  keys  to  a 
successful  Design  to  Cost  Program. 

1.4  OBJECTIVES 

To  establish  cost  as  a parameter  equal  tr  importance  with  tech- 
nical requirements  and  schedules  throughout  the  design,  development, 
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production,  and  operation  of  weapon  systems,  subsystems  and  com- 
ponents. 

To  establish  cost  elements  as  management  goals  for  acquisition 
managers  and  contractors  to  achieve  the  best  balance  between  life 
cycle  cost,  acceptable  performance  and  schedule. 

Establishment  of  cost  as  an  active  rather  than  a resultant 
parameter  Is  the  key  to  the  first  objective.  This  requires  coet 
becoming  as  tmich  as  technical  challenge  to  the  people  involved  with 
design  and  development  as  performance  and  capability  have  been  in 
the  past.  Acquisition  managers  must  be  aware  of  and  control  cost 
in  all  phases  of  the  program  and  be  prepared  to  consider  the  ef- 
fects 0.1  cost  before  making  each  program  decision. 

The  second  part  of  the  objective  involves  the  identification 
and  establishment  of  cost  elements  as  management  goal  to  accomplish 
the  desired  balance  between  performance  cost  and  schedule.  Accom- 
pllslraent  here  requires  the  integration  of  projected  cost  into  the 
management  of  systems,  subsystems  and  component  design.  Finite 
funding  realities  must  be  considered,  the  program  DTC  goal  must  be 
established  and  management  methodology  developed  to  provide  neces- 
sary visibility  for  cost  and  design  control. 

1.5  DEFINITION® 

1.5.1  Design  to  Cost  Goal.  At  this  stage  of  the  DTC  concept  devel- 
opment, DODD  50G0.28  requires  that  a program  have  only  a single  mon- 
etary DTC  goal.  This  DTC  goal  is  an  average  unit  flyaway  cost  goal 
(a  production  cost  element)  established  by  the  Secretary  of  Defense 
for  major  programs  and  by  higher  designated  authority  within  each 


Service  for  less  than  oiajor  programs,  as  soon  as  possible  but  not 
later  than  entry  Into  Engineering  Development  (Milestone  II).  The 
process  by  which  this  goal  is  established  is  discussed  in  consider- 
able detail  in  Section  4.0,  however,  it  is  to  be  stressed  here,  that 
this  goal  is  an  in-house  govemntent  goal,  almost  contractual  in  na- 
ture, between  the  ?M  (Service)  and  the  Secretary  of  Defense. 

It  is  the  Intent  that,  within  the  constraints  of  this  official 
DTC  goal,  the  PM  be  given  the  authority  to  divide  this  goal  into 
cost  elements,  controlled  by  him,  to  suit  the  structure  of  his  in- 
dividual program  and  to  make  trade-offs  between  these  cost  elements 
as  decided  by  him  without  need  for  approval  from  the  OSD.  A further 
breakdown  of  these  elements  or  subgoals  will  form  contractual  DTC 
targets  for  the  various  contractors  supporting  the  program. 

1.3.2  Operation  and  Support  Cost  (k>als«  DODD  5000.28  also  requires 
as  a part  of  the  DTC  concept,  goals  for  O&S  cost  factors.  Until  the 
data  base  concerning  O&S  cost  by  pregram  is  sufficiently  strength- 
ened, monetary  cost  goals  are  not  required  at  this  time  to  be  part 
of  the  official  DTC  goal,  although  they  are  in  no  way  prohibited  if 
considered  feasible  by  the  PM.  Major  O&S  cost  factors  are  required 
to  have  goals  established  in  the  form  of  some  measureable  number 
which  can  be  monitored  during  test  and  evaluation  as  well  as  opera- 
tion. Some  of  these  elements  nre  cuxnrently  required  by  service 
regulations  and  MIL  Specs  and  others  will  be  established  by  the  FM, 
subject  to  review  for  adequacy,  to  influence  the  design  and  tc  con- 
trol OfiS  cost.  See  Section  4.3  for  additional  discussion  of  O&S 
goals. 


1.5.3  Aviiraae  Unit  Flyaway  Cost.  This 'Is  the  cost  element  defined 
by  DODD  3000.28  that  will  be  used  for  establishing  the  Design  to 
Cost  goal  for  a program  by  the  Secretary  of  Defense.  It  is  based 
on  guidance  in  DOD  Budget  Manual  7110. IM  of  flyaway  cost  to  be  used 
with  missiles  and  aircraft  in  the  budget  process.  For  programs  in- 
volving hardware  other  than  aircraft  and  missiles,  it  will  be  neces- 
sary for  the  PM  to  define  his  average  unit  production  cost  using 
this  guidance  as  a model,  e.g.  rollaway  cost  for  vehicles,  sallaway 
cost  for  ships  or  average  unit  production  cost  for  other  hardware 
items. 

1.5.4  Contractual  PTC  Targets.  A contractual  DTC  target  is  that 
portion  of  the  program  goal  over  which  the  contractor  has  control. 
Contractual  DTC  targets  for  the  production  phase  should  address 
only  the  system  elements  which  are  supplied  by  the  contractor.  For 
these  elements  it  should  include  those  elements  of  cost  which  are 
Included  in  the  program  average  unit  flyaway  cost  goal  at  the  pro- 
gram level.  DTC  targets  for  design  controllable  operating  and 
support  costs  should  be  structured  to  fit  only  the  system  elements 
covered  by  the  contract  and  will  be  expressed  in  meaningful  terms 
which  can  be  measured  during  operational  testing  or  by  an  early 
point  in  the  operational  life  of  the  system.  Where  appropriate 
(normally  for  subsystems),  operating  and  support  DTC  targets  may 
also  be  defined  in  the  form  of  warranties,  particularly  operational 
Reliability  Improvement  Warranty  (RIW)  commitments. 
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1.5.5  Operating  and  Support  Cost.  O&S  costs  are  those  resources 
required  to  operate « and  support  a system,  subsystem,  or  a major 
component  during  its  useful  life  in  the  operational  inventory. 

1*5.6  Life  Cycle  Cost  (LCC).  The  LGC  of  a system  is  the  total 
cost  to  the  Government  of  that  system  over  its  full  life.  It  in- 
cludes the  cost  of  development,  production,  operation,  support,  and 
where  applicable,  disposal. 


2.0  APPLICABILITY  OF  DESIGN  TO  COST  CONCEPTS 


2.1  WHAT  DEVELOPMENTS? 

2.1.1  Design  to  Cost  is  applicable,  and  must  be  applied,  to  every 
development  and  product  Improvement  or  modification  of  systems, 
subsystems  and  componen'js.  Major  Systems  meeting  the  criteria  of 
DODD  5000.1  will  have  their  DTC  prcgram  reviewed  by  the  DCP/DSARC 
process  and  will  have  DTC  goals  established  by  the  Secretary  of 
Defense.  Programs  not  meeting  the  DCP/DSARC  criteria  will  be  re- 
viewed by  an  appropriate  authority  within  each  Service  in  accord- 
ance with  individual  service  directives.  DTC  criteria  and  goals 
for  subsystems  and  components  will  flow  down  from  programs  within 
which  they  will  be  used  or  established  directly  by  sponsoring  com- 
mands. Applications  will  vary  from  one  program  to  another  as  to 
which  costs  are  managed,  the  way  the  management  is  accomplished 
and  other  specifics.  However,  the  one  principle  element  which  is, 
and  must  be,  common  to  all:  cost  must  be  a consideration  in  de- 
sign. 

2.1.2  DOD  Directive  5000^28  recognizes  only  one  exemption  to  ap- 
plication of  DTC  for  major  systems;  those  very  few  programs,  which 
for  reasons  of  national  security,  have  performance  or  schedule 
goals  that  take  priority  over  cost  goals.  This  exemption  can  only 
be  authorized  by  the  Secretary  of  Defense.  Avxthorlzatlon  for  this 
exemption  in  the  cases  of  non-major  systems,  subsystems  and  com- 
ponents will  be  made  at  a management  level  above  the  Program  Mana- 
ger as  dictated  by  Departmental  instructions. 
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2.1.3  For  very  low  dollar  efforts,  such  as  the  development  of  low 
value  components,  the  effectiveness  of  the  application  of  Design 
to  Cost  must  be  evaluated  in  terms  of  the  uncertainty  and  design 
sensitivity  of  production  costs  and  the  degree  to  which  the  com- 
ponent's design  sensitive  contribution  to  operating  and  support 
costs  can  be  identified.  Also  a significant  factor  is  the  extent 
to  which  comj>onent  configuration  and  specifications  are  dictated 
by  requirements  to  interface  with  higher  level  subsystems  and  sys- 
tems. Where  there  is  little  room  for  design  flexibility  and  little 
cost  uncertainty,  the  application  of  DTC  may  not  be  economical. 

However,  in  most  cases,  the  application  of  Design  to  Cost  re- 
quirements to  the  development  of  components  and  subsystems  is  nec- 
essary and  makes  an  effective  contrlbuv  ' to  the  overall  objective 
of  controlling  defense  costs*  Systems  are  made  up  of  subsystems 
and  components.  If  the  costs  of  these  building  blocks  are  not  con- 
trolled, systems  costs  cannot  be  controlled.  Particular  emphasis 
should  be  placed  on  controlling  the  costs  of  subsystems  and  com- 
ponents which  are  used  in  more  than  one  system. 

2.1.4  Government  Furnished  Equipment  (GFE) . Control  and  account- 
ability of  DTC  goals  and  design  criteria  for  GFE,  particularly  GFE 
used  as  standard  items  in  several  programs  is  important  to  Program 
Managers.  These  components  make  up  a cost  element  of  the  Program 
Managers  DTC  goal  and,  more  often  than  not,  are  acquired  by  pro- 
curement activities  not  under  the  control  of  the  PM.  As  stated 
above,  control  of  these  cost  is  absolutely  essential  and  the  pro- 
curement management  systems  established  by  commodity  commands  for 
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programs . 

2.1.5  System  Modifications 

Product  improvement  or  modification  of  existing  systems  can 
be  a highly  economical  way  of  obtaining  Increased  utility  In  many 
cases;  however.  It  presents  a special  set  of  circumstances  for  the 
application  of  Design  to  Cost.  The  design  effort  usually  involves 
only  specific  portions  of  the  system  with  the  objective  of  achiev- 
ing limited  but  significant  improvements  In  system  utility.  In 
some  cases  these  utility  Improvements  may  specifically  be  signifi- 
cant reductions  in  production  and/or  operating  and  support  costs. 

In  most  instances*  the  objective  will  be  to  upgrade  performance  to 
meet  a new  or  Increased  threat.  In  many  cases*  the  likely  product 
of  the  design  effort  will  be  a set  of  changes  Introduced perhaps 
not  concurrently,  into  on-golng  production.  Both  design  flexibil- 
ity and  production  cost  measurability  are  likely  to  be  more  limited 
than  In  the  development  of  a new  system.  However,  these  are  par- 
tially compensated  for  by  lower  risk  and  less  uncertainty  regarding 
production,  operating  and  support  costs. 

Major  modifications  to  coinpleted  systems;  e.g.,  wing  re-deslgr. 
or  fuselage  stretch  of  an  existing  transport  aircraft,  upgrading 
and  modernization  of  a tank,  are  appropriate  for  application  of  !/rC. 
Although  there  may  be  relatively  Iw/  levels  of  design  flexibility, 
the  high  level  of  investment  in  major  rework  modifications  and  the 
increased  ability  to  project  costs  based  on  past  experience  with 
the  system,  justify  the  effort  to  identify  valid  cost  trade-offs. 
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In  general,  the  application  of  If£C  to  system  modifications 
should  be  restricted  to  those  parts  of  the  system  which  are  being 
redesigned  or  added  to  increase  performance.  If  the  planned 
changes  in  configuration  are  minor,  the  application  of  DTC/goals 
may  not  be  justified.  For  major  revisions  to  the  system,  DTC  is 
mandatory.  Between  the  two  extremes,  judgment  is  required.  Fac- 
tors which  should  be  considered  in  applying  BTC  to  design  modifi- 
cation programs  include:  (1)  the  extent  of  the  modification; 

(2)  the  potential  to  reduce  future  costs  of  the  systems;  (3)  the 
me^urabillty  of  production,  operating  and  support  cost  changes  to 
the  system  which  may  result  from  design  changes;  (4)  the  poten- 
tial of  design  changes  beyond  the  absolute  mlnimtnn  essential  to 
meet  performance  needs  to  be  sufficiently  cost  effective  to  com- 
pensate for  increased  development  costs,  cost  of  tooling,  loss  of 
production  learning,  and  loss  of  commonall*:y  (for  support  purposes) 
with  earlier  versions  of  the  system  and  (5)  affordability  and/or 
ftmds  available  for  the  modification.  The  selection  of  which  parts 
of  s system  are  to  be  replaced  or  Improved,  as  well  as  the  design 
of  replacements  or  improvements  are  all  subject  to  cost  considera- 
tions. The  existence  of  baseline  data  for  current  system  costs 
and  performance  normally  allows  the  generation  of  relatively  pre- 
cise estimates  of  future  cost  and  performance  to  facilitate  this 
selection. 

2.2  WHEN  TO  APPLY? 

For  major  systems,  BOB  Directive  5000.28  requires  the  estab- 
lishment of  Beslgn  to  Cost  goals  not  later  than  entry  into  Full 
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Scale  Development  and  encourages  Its  application  es  early  as  po8sl-> 
ble  prior  to  that  milestone.  For  any  development  program.  Design 
to  Cost  concepts  must  be  applied  prior  to  the  establishmer.t  of 
firm  designs.  Later  introduction  will  be  less  effective  because 
the  design  cannot  be  changed  to  accommodate  costs  or  because  the 
change  would  be  uneconomical  because  of  the  cost  or  schedule  impact. 
In  addition,  the  visibility  of  costs  provided  by  tracking  the  es- 
timated production  and  operating  and  support  costs  is  valuable  ,to 
management  in  controlling  cost  growth  during  this  phase. 

2.2.1  Concepttial  Phase 

In  every  review  of  Design  to  Cost  applications  to  dat'.i,  the 
need  for  the  earliest  introduction  of  cost  as  a design  parameter 
has  been  verified.  Although  not  strictly  within  the  purvlar  of 
this  Guide,  the  requirements  generation  phase  is  that  in  which 
cost  consideration  can  have  the  greatest  impact.  In  analyzing  the 
possible  waye  of  countering  a threat  or  of  supplying  a needed  cap- 
ability, the  cost  of  each  of  the  possible  ways  must  be  balanced 
against  the  effectiveness  and  affordability  of  each.  Uncertainty 
surrounding  cost  estimates  at  this  stage  is  very  large  and  point 
estisiates  taay  be  grossly  in  error.  Thus  cost  considerations  should 
be  in  terms  of  relative  cost  differentials  between  con^eting  con- 
cepts 3t  this  stsgs  of.  devslojsBsnt « 

As  the  conceptual  phase  continues,  the  objective  should  be  to 
identify  viable  system  alterxiatlves.  The  major  differences  in 
development,  production,  operating  and  support  costs  for  the  system 
alternatives  under  study  should  be  analyzed  and  evaluated.  As  part 
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of  this  process  the  performance  and  configuration  characteristics 
having  the  greatest  influence  on  costa  shoxild  be  identified.  Where 
relevant,  the  lncre<nental  costs  associated  with  various  levels  of 
performance  should  be  determined.  This  approach  introduces  cost 
considerations  and  discipline  into  the  design  process  and  provides 
the  necessary  background  for  the  establishment  of  realistic  perfor-' 
mance  thresholds  and  cost  ceilings  at  the  entrance  into  the  valida- 
tion phase.  (Milestone  I) 

For  high  technology  prograi^,  in  which  the  state-of-the-art  is 
fluid,  or  where  maximum  performance  to  meet  the  threat  is  more  im- 
portant than  cost,  the  use  of  firm  cost  goals  may  be  self-defeating 
in  concept  formulation  and  the  earlier  stages  of  advanced  develop- 
ment. Rapidly  advancing  technology  may  either  make  firm  goals  too 
high  or  too  low,  driving  decisions  to  less  than  the  best  balance 
between  performance  schedule  and  costs.  In  these  situations  cost 
should  be  allowed  to  vary  with  the  advancing  technology  by  esti- 
mates made  and  confirmed  with  each  major  concept  or  design  event. 

As  stated  previously,  these  thresholds  and  ceilings  are  gen- 
erally not  refined  to  the  point  of  establishing  firm  goals  at  this 
point,  but  represent  objectives  which  are  to  be  validated  during 
Advanced  Development.  An  analysis  of  the  affordability  of  these 
objectives  should  have  been  completed  and  reported  by  this  Hlls- 
etone. 

liXie  cycle  cost  estimates  are  required  in  the  Decision  Ck>- 
ordinating  Paper  (DGP)  at  Milestone  I (and  at  comparable  points 
for  non-major  83r8teme  and  subsysteaa).  These  will  be  based  on  the 
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preferred  system  alternatives  from  the  concept  formulation  phase. 

2.2.2  Validation  Phase 

The  result  of  Design  tc  Cost  application  in  validation  should 
not  be  completely  liiaited  to  comirg  within  the  established  point 
cost  goals.  The  specific  cost  goals  established  for  this  phase 
shculd  be  viewed  as  targets  about  which  visibility  into  the  cost 
consequences  of  differing  alternate  or  IncrementEd  performance  or 
design  features  can  be  measured  and  assessed  for  effectiveness. 
Appropriate  elements  are  the  base  for  and/or  must  reconcile  wir.h 
the  Design  to  Cost  goals  for  the  validation  phase  whether  they  be 
interim  or  firm  goals.  Throughout  the  validation  phase  the  cost 
effectiveness  of  performance  characteristics  and  levels  and  other 
design  characteristics  should  be  assessed  in  terms  of  their  effects 
on  DTC  goals  and  the  LCC  estimate  in  order  to  arrive  at  the  best 
affordable  mix  of  system  performance  and  tojts. 

The  ’Ultimate  purpose  of  the  Design  to  Cost  effort  during  the 
Validation  Phase  of  a program  ie  to  provide  the  information  to 
recommend  and  justify  a firm  Design  to  Cost  goal  for  the  alterna- 
tives, both  preferred  and  backup,  as  soon  as  possible  but  not  later 
than  the  presentation  for  the  decision  tc  enter  Full  Scale  Develop- 
ment (DSABC  Milestone  II) . 

2.2.3  Full  Scale  Development 

The  Hilestoue  II  decision  to  enter  Full  Scale  Development  nor- 
mally includes  selecting  the  one  system  to  be  developed  from  among 
the  competing  concepts  and  design  or  performance  characteristics. 

As  such,  it  freezes  the  design  approach.  Initial  application  of 


Deulgn  to  Cost  at  this  point  In  the  development  cycle,  while  manda- 
tory, cannot  be  expected  to  yield  i-eaults  in  the  magnitude  that 
earlier  application  would  produce.  Because  the  overall  performance 
characteristics,  basic  design  configuration  and  unit  cost  goal  have 
been  established,  flexibility  to  trade  these  elements  for  cost  con- 
siderations is  significantly  lessened.  However,  even  with  many  of 
the  design  decisions  made,  cost  can  continue  to  be  t:sed  at,  a design 
parameter  to  control  the  manner  in  which  the  chosen  design  is  exe- 
cuted. 

With  a prior  application  in  Advanced  Development,  application 
of  Design  to  Cost  in  Full  Scale  Development  is  greatly  enhanced. 
Cost  discipline  is  already  present  in  the  selected  concept  and  in 
the  minds  of  the  designer  and  decision  maker.  Much  more  Jj  known 
of  the  cost  impact  of  selection  among  alternate  designs.  There  is 
a better  Indication,  as  a result  of  test  experience  in  advance 
development,  of  the  operating  and  support  costs  of  the  design. 

While  produclblllty  must.be  considered  even  in  the  earliest 
phases  of  development,  it  is  a key  ingredient  of  Full  Scale  Devel- 
opment. Froduclblllty  and  maintenance  engineering  of  the  selected 
design  are  basic  and  necessary  methodologies  of  designing  to  cost. 
2. 2. A Summarizing,  Design  to  Cost  should  be  applied  early  in  the 
development  cycle.  Its  largest  Impact,  in  terms  of  alternative 
expenditures  comes  first  in  requirements  generation,  the  concep- 
tual phase,  then  the  validation  phase  and  last  in  the  Full  Scale 
Development  phase.  Prior  to  Full  Scale  Development,  one  of  the 
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principal  roles  of  cost  as  a design  parameter  is  to  yield 
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information  upon  which  to  base  ‘“.ciaions  as  to  alternative  con- 
cepts and  designs  and  as  to  Incremental  performance  features. 
Without  full  implementation  of  the  Design  to  Cost  concepts,  these 
declf'ions  may  be  made  without  regard  to  downstream  cost  Impacts. 
Application  in  Full  Scale  Development  mandatory.  Since  it  is 
the  last  point  at  which  design  can  be  readily  influenced  by  cost. 
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3.0  GENERAL  REQUIREMBNTS 


There  are  certain  basic  considerations  which  toast  be  addressed 
if  designing  to  cost  Is  to  be  successful.  The  most  Inqtortant  of 
these  are  discussed  in  this  section.  Variances  in  these  basic  con- 
ditions are  the  drivers  in  the  type  and  extent  of  application  of 
Design  to  Cost  in  each  program. 

3.1  FLEXIBILITY 

Flexibility  is  the  degree  of  freedom  of  choice  and  decision 
given  to  the  designer  by  the  way  in  t^ilch  the  system  is  described 
in  its  specifications  and  the  way  in  which  our  time  needs  are  ex- 
pressed. If  the  specifications  are  very  detailed  ind  rigid,  tliey 
dictate  the  design  choice.  If  the  specifications  contain  design 
rather  than  performance  requirements,  there  is  no  design  choice  at 
all.  If  schedules  are  sufficient  for  only  one  cycle  of  design  and 
test,  or  If  they  are  detailed  ns  f',  in-process  milestones,  there 
Is  little  opportunity  to  take  advantage  of  any  flexibility  in  the 
specifications. 

There  are  certain  guidelines  which  should  be  followed  in  order 
to  achieve  the  flexibility  which  is  necessary  for  effective  appli- 
cation of  Design  to  Cost. 

1.  Specify  the  result  needed,  not  the  way  to  obtain  the  result. 

2.  Specify  performance,  not  design. 

3.  Specify  performance  and  cost  for  the  system,  not  for  sub- 
systems or  components V 


4.  Initially  specify  the  end  date  of  the  schedule,  not  interim 
milestones. 


) 


I 


5.  Schedule  programs  with  time  for  several  iterations,  not 


on  a 1007.  success  basis. 

There  may  be  valid  reasons  for  departing  from  these  guidelines 
In  every  program.  When  a departure  Is  proposed,  the  reasons  for  it 
should  be  carefully  examined.  This  is  particularly  true  of  the  u«e 
of  Federal  or  Militfiry  Specif  ^.cations  and  Standards.  There  is  no 
need  to  use  these  simply  because  they  exist.  Their  use  depends 
upon  the  reason  for  their  existence  and  the  degree  to  which  full  or 
partial  use  will  satisfy  that  reason.  Handatory  application  of 
these  specifications  and  standards  should  be  a\*oided  in  advance 
development  and  contractors  should  be  required  to  address  the  ex« 
tent  of  application  in  writing  the  ^ecification  for  use  in  Full 
Scale  Development. 

Flexibility  of  another  type  is  necessary  in  the  way  in  which 
production,  operating  and  support  costs  are  Interrelated.  The 
structure  of  these  goals,  thel'^  tracking  and  management,  must  not 
preclude  the  identification  of  significant  opportunities  for  trade- 
offs among  the  different  elements  of  life  cycle  cost. 

The  PM  and  each  competing  contractor  must  have  maximum  freedom 
to  provide  their  version  of  the  best  possible  design  to  perform  the 
mission  at  the  established  cos<:  goal.  As  an  example,  the  unit  pro- 
duction cost  goal  should  related  to  only  the  minimum  nui!di>er  of 
csscntinl  performance  and  schedule  requirements.  This  will  allow 
the  PM  and  contractor  the  flexibility  needed  to  make 
among  life  cycle  cost  elements,  schedule  and  performance  require- 
ments are  met.  If  redesign  cannot  achieve  the  cost  goal,  there 
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must  be  a vd.lllngness  to  trade-off  desired  performance  to  achieve 
the  cost  goals  while  asnurlng  a viable  weapon  system  design  Is  ob- 
tained. To  this  end,  both  contractor  and  Service  project  manager 
must  have  early  visibility  of  the  expected  costs  associated  with 
the  emerging  design. 

A Design  to  Cose  program  requires  control  of  design  changes 
which  are  beyond  the  scope  of  the  initial  contract  deslgn/perfoisn- 
ance  rsqulrements.  Changes  may  be  proposed  for  many  reasons;  to 
improve  performance,  to  solve  design  problems,  or  to  lower  produc- 
tion, and/or  operating /support  costs.  Effect  of  the  change  on  life 
cycle  cost  and  an  analysis  of  the  effect  on  system  performance  Is 
needed.  The  proposed  change  should  be  reviewed  on  the  basis  of  its 
cost  effectiveness.  Only  those  changes  offering  benefits  which 
outweigh  their  costs  and  which  are  con^atible  with  the  achievement 
of  the  Design  to  Cost  goal  should  be  authorized.  For  example,  con- 
tractor introduction  of  new  low-cost  piece  parts  to  achieve  a 
lower  production  cost  may  actually  prove  mere  expensive  If  more 
reliable  and  standard  piece  parts  are  used  for  replacement  after 
the  hardware  enters  the  operational  Inventory. 

3 . 2 STANDARDIZATION 

In  many  applications  of  Design  to  Cost  the  question  arises 
whether  to  use  a part  already  in  the  inventory  or  to  create  a new 
design  or  select  another  part  not  in  the  inventory. 

This  question  must  be  a consideration  in  vdesign  decisions, 
particularly  from  the  standpoint  of  support  costs*  Relative  costs 
must  be  weighed  for  each  alternative.  While  lower  priced  non- 
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standard  parts  nay  be  available*  lower  reliability,  the  cost  of 
introduction  of  a new  part  into  the  system  and  the  cost  of  main> 
talning  multiple  parts  of  coinreiipouding  function  may  offset  the 
lower  Initial  cost. 

3.3  BASELINE  DATA 
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3.3.1  Whatever  cost  is  to.be  made  a design  parameter,  (production, 
operating  and/or  support,)  there  should  be  a set  of  underlying 
assun^tions,  facts  or  other  bases  which  lead  to  the  stated  estimate 
or  goal.  The  most  significant  of  these  are: 

1.  Definition  of  the  unit  production  cost  goal  in  accordance 
with  the  DOD  Budget  Guidance  Manual  (DOD  7110.1  M). 

2.  Definition  of  the  elements,  of  operating  and  support  costs 
wltich  will  be  program  cost  goals. 

3.  Identification  of  the  elements  of  the  Work  Breakdown 
Structure  to  which  the  costs  are  associated. 

4.  Cost  elements  to  be  considered  such  as  recurring,  non- 
recurring, labor,  overhead,  subcontracts,  G&A,  profit,  etc< 

5.  Anticipated  production  quantity,  rate  of  production,  time 
of  production,  and  Increments  of  production  and  learning  curve,  and 
provisions  for  accomoodating  'hanges  to  these  factors. 

6.  Provision  for  acconmodation  of  changing  economic  conditions 
including  constant  dollar  base  year,  Indices  to  be  used  to  deflate 
out  year  dollars,  etc. 

7.  DepLoyiaent  concepts  such  as  how,  where  and  when  the  system 
is  planned  for  use. 

3.  Operational  mi,ssion(s)  and  environment, 
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9.  Maintenance  concepts  such  as  how,  where,  when  and  by  whom 
will  Che  system  be  raincained. 

10.  Models  £or  estimacivig,  tracking  and  assessing  life  cr^le 
costs. 

11.  liqmts  to  cost  models  which  are  Govexrnnent  generated  or 
controlled  such  as  labor  and  overhead  costs  of  Government  mainte- 
nance, cost  of  POL,  cost  of  Inventory,  Introduction  and  maintenance, 
coats  of  training,  etc. 

3.3^2  Oertnln  of  these  baseline  data  are  generally  specified  by  the 
GcvemaenC.  The  remaining  data  are  arrived  at  by  evolution  during 
the  development  cycle  as  Che  design  matures.  Much  of  these  data 
will  be  generated  in  advance  development  and  will  i.crm  part  of  the 
baseline  for  full  scale  development. 
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4.1  Design  to  Cost  goals  are  single  point  estimates  of  various  ele- 
ments of  Life  Cycle  Cost  which  are  made  a part  of  Decision  Coordi- 
nating Papers  (C€P)  for  ma;'or  systems.  Goals  established  for  non- 
major  systems,  subsystems  and  components  are  similarly  documented 
In  appropriate  Service  approvals. 

4.2  DOD  Directive  5000.28  requires  the  establlshnicrit  of  a Design 
-o  Cost  goal  for  production  as  defined  in  1.5.3  as  flyaway  cost  per 
DOD  7110. IM.  The  Directive  recognizes  rare  Instances  in  which  fly- 
away cost  would  not  be  the  most  appropriate  goal  and  permits  the 
proposed  use  of  weapon  system  cost,  procurement  cost,  program  ac- 
quisition cost,  or  other  category  defined  in  DOD  7110. IM. 

4.3  A nrogram  can  have  one  or  xaore  design  to  cost  goals.  Not  all 
goals  ere  appropriate  to  all  programs  and  care  must  be  taken  in 
application  of  suitable  design  to  cost  goals. 

Where  operating  and  support  costs  are  a significant  factor, 
it  would  be  appropriate  to  propose  operating  and  support  cost  goals 
which  look  at  that  portion  which  is  design  dependent,  predictable 
and  verifiable.  This  would  include  such  things  as  direct  crew  cost, 
spares,  direct  maintenance  manhours,  material,  training,  support 
equipment,  inventory  management,  technical  data  and  maintenance 
associated  records  and  transactions,  facilities  and  POL.  As  a mini- 
mum, goals  for  reliability  and  maintainability'  should  be  specified. 
However,  in  order  to  balance  all  the  elements  of  production,  oper- 
ating and  support  costs,  with  performance  and  schedule,  particularly 
in  order  to  choose  among  alternative  designs,  it  is  necessary  to 
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convert  the  measures  of  reliability  and  maintainability,  such  as 
KTBF  and  MTTR,  Into  expressions  of  cost. 

Pending  the  development  of  a suitable  data  base  for  use  In 
creating  Cost  Estlmtlng  Relationships,  the  conversion  of  design 
characterlsciics  such  as  reliability  and  malntalniblllty  Into  cost 
Is  possible  through  the  use  of  cost  models.  (A  bibliography  of 
cost  models  Is  available  through  DLSIE.)  However,  they  have  not 
demonstrated  high  degrees  of  precision  in  reflecting  or  predicting 
absolute  costs.  These  cost  models  are,  however,  useful  In  assess- 
ing cost  differentials  between  competing  or  alternate  designs  and 
thus  are  useful  for  Design  to  Cost  purposes. 

4.4  Design  to  cost  goals  for  operating  and  support  costs  are  es- 
sential to  the  management  and  control  of  these  costs  which  have 
been  escalating  at  alarming  rates. 

The  major  design  characteristics  which  drive  operating  and 
support  costs  are  reliability,  maintainability,  price  for  spare 
pares  and  support  equipment.  The  most  rudimentary  goals  for  oper- 
ating and  support  cost  would  be  definitive  statements  of  require- 
ments in  these  areas. 

One  of  the  most  basic  and  fxniitful  approaches  to  controlling 
operating  and  support  cost  Is  the  control  and  reduction  of  manpower 
requirements  In  the  operation  and  support  of  systems.  Manpower  has 
become  the  most  expensive  element  of  the  DOD  budget.  This  is  re- 
flected in  increased  systems  costs  of  operating  crew,  size,  skills 
and  training,  and  maintenance  manpower  requirements  of  nuinbers  of 
maintenance  personnel,  their  skills  and  training. 
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Detigii  rjuit  address  t:he  costs  of  manpower.  Crew  size,  consis- 
tent with  operational  necessity,  can  be  balanced  against  hardware 
sophistication  to  obtain  tne  lowest  overall  costs.  Normally,  im- 
provements in  reliability  reduce  the  need  for  maintenance  manpower. 
Advances  in  maintainability,  by  reducing  maintenance  time,  reduce 
manpower  requirements.  Generally,  both  reliability  and  maintain- 
ability can  be  enhanced  through  sliiq>ler  designs,  thus  contributing 
to  lower  production  costs.  Even  when  enhanced  reliability  and 
maintainability  are  obtained  at  increased  production  cost,  the 
resulting  manpower  cost  savings  may  be  expected  to  result  in  over- 
all savings  to  the  DOD. 

4.5  Design  to  Cost  goals  for  tmijor  systems  are  proposed  by  the 
Program  Manager  and  the  Services  and  are  established  by  the  Secre- 
tary of  Defense  in  the  DGP. 

These  goals  are  drawn  from  the  life  cycle  cost  estimates  re- 
quired in  support  of  the  DCP.  At  each  milestone  the  maturity  of 
the  estimates,  and  thus  the  goals,  increases  with  the  maturity  of 
the  concept  and  design.  In  this  sense,  the  Design  to  Cost  goals 
are  flexible  requirements  and  are  subject  to  change,  as  approved 
by  the  Secretary  of  Defense,  as  performance,  quantity  and  concept 
changes  occur  and  opportunities  for  life  cycle  cost  trade-offs 
arise.  Absent  such  causes,  the  Design  to  Cost  goals  are  to  be 
created  as  firm  and  are  a basis  for  assessing  tl^  performance  of 
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In  each  case,  the  authority  establishing  the  goals  must  be  higher 
than  the  Program  Manager. 

4.6  A principle  characteristic  of  a Design  to  Cost  goal  is  that 
it.  should  be  difficult  but  achievable.  If  the  goal  is  toe  high, 
there  is  no  motivation  toward  cost  reduction  through  critics;!  exam- 
ination of  requirements,  concepts  and  designs.  This  may  result  in 
acquiring  Incremental  performance  or  design  features  which  are  not 
cost  effective.  Conversely,  if  the  goal  is  too  low,  motivation  is 
destroyed  because  no  amount  of  trade-off  could  be  expected  to  a- 
chleve  the  goal. 

It  is  also  essential  that  the  goals  selected  be  relatable  di- 
rectly to  the  life  cycle  cost  estimates  which  support  the  DCP  or 
budget  submissions. 

4.6.1  Hardware  Elements.  The  program  unit  production  cost  goal 
.should  Include  each  element  of  hardware  that  will  be  procured  for 
the  flyaway  (sailaway,  rollaway)  unit  of  the  defense  system.  This 
includes  both  Gl^  and  GFE  items.  In  those  few  instances  where  it 
is  not  practical  to  establish  a comprehensive  design  to  unit  produc- 
tion cost  goal  for  a system  what  is  and  what  is  not  Included  In  the 
goal  should  be  clearly  specified.  Likewise  when  operating  and  sup- 
port cost  goals  are  established  the  hardware  elements  covered  by 
the  goaKs)  should  be  clearly  documented. 

In  some  Instances  it  will  be  necessary  to  establish  individual 
design  to  unit  produc.tlon  cost  goals  for  the  various  subsystems 
within  a system  acquisition  prograia.  This  will  be  primarily  in 
those  cases  where  different  and  basically  tmrelated  quantities  of 
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subsyatema  are  to  be  procured  and/or  when  a oubsysten  may  be  coi.xson 
Co  two  or  iQore  programs;  e.go»  X number  of  missiles  and  Y number  of 
fire  control  systems.  In  the  cases  of  operating  and  support  costs » 
it  will  in  many  cases  be  more  feasible  to  establish  operating  and 
support  goals  for  the  subsystems  of  major  systems,  rather  than  at 
the  total  system  level. 

Where  unit  production  cost  goals  Include  GFE,  it  will  be  neces> 
sary  for  the  manager  responsible  for  Che  system  acquisition  to  have 
the  appropriate  communication  and  control  of  the  GFE.  If  a GFE 
item  is  being  developed  for  incorporation  into  only  one  system, 

Che  manager  of  that  system  should  have  effective  control  of  the 
DTC  effort  for  that  GFE  item.  If  GFE  is  being  developed  for  more 
than  one  system,  the  DTC  goal(s)  for  the  GFE  should  be  treated  as 
part  of  the  configuration  and  performance  interface  with  the  sys- 
tems and  controlled  accordingly.  This  latter  condition  also  applies 
to  the  unit  production  cost  and  other  DTC  data  for  a fully  developed 
(production)  GFC  element  which  is  a part  of  system  being  managed  in 
accordance  with  DTC  policy. 

It  is  vitally  necessary  that  prime  contract  design  to  unit 
production  cost  goals  include  CFE  hardware  elements  and  that  the 
prime  contractor  take  positive  action  to  obtain  CFE  within  the  unit 
production  cost  goal  and  which  make  the  proper  contribution  to  the 
achievement  of  operating  and  support  goals.  This  should  be  done 
through  the  application  of  DTC  goals  and  provisions  to  subcontracts 
sad /or  by  other  appropriate  means. 
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In  &1.1  000685  th'<3  objective  is  to  have  the  program  unit  produc- 
tion coat  goat  reflect  the  full  procurement  costs  of  the  basic  sys- 
tem. This  should  he  the  principal  guideline  in  determining  what 
will  be  included  in  this  goal.  Items  normal^.y  Included  in  major 
system  goals  are:  (1)  the  basic  system  unit,  (2)  the  propulsion 
subsystem  Including  accessories,  (3>  armament  which  is  normally 
installed  in  or  procured  for  the  basic  system,  (4)  all  comaunlca- 
tlons,  navigation  and  other  electronics  which  are  Integrated  into 
the  system,  and  (5)  all  other  GFE  and  CFS  which  are  part  of  the 
operating  system.  Hardware  which  are  not  included  In  the  unit  pro- 
duction: cost  goal  Include  system  peculiar  and  special  support  e- 
quipment,  special  training  equipment  and  initial  spares  and  repair 
parts  (unless  normally  Included  in  the  operating  system).  However, 
it  is  necessary  that  these  items  be  considered  in  the  life  cycle 
cost  management  of  the  system  and  that  appropriate  goals  be  estab- 
lished for  this. 

4.6.2  Cost  Elements.  The  program  unit  production  cost  goal  is  re- 
quired to  conform  to  the  guidance  regarding  Average  Unit  Flyaway 
Cost  for  aircraft  and  missiles  contained  in  DOD  Budget  Guidance 
Manual  7110. IM.  Programs  developing  other  types  of  systems  should 
follow  this  guidance  as  closely  as  practical  and  include  all  ele- 
ment appropriate  to  their  equipments.  Basically  the  goal  should 
Include:  (1)  the  recurring  and  nonrecurring  production  costs  for 
all  hardware  elements  of  the  system,  (2)  an  allowance  for  fee/proflt, 
(3)  an  allowance  for  changes  which  is  normally  a percentage  of  the 
estimated  unit  cost  of  the  current  configuration  based  on  historical 
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experience,  and  (4)  any  management  reserve  which  the  program  manager 
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' is  able  to  retain.  It  should  be  understood  that  only  the  first  ele- 

ment will  be  reflected  in  contract  design  to  unit  production  cost 
goals  and  then  only  for  the  hardware  elements  covered  by  that  par- 
ticular contract. 

For  DIG  goals  for  operating  and  support  costs  the  guidance  is 
principally  that  goals  be  established  for  the  elements  of  these 
costs  (or  cost-driving  factors)  which  are  design  controllable  and 
can  be  measured  no  later  than  an  early  stage  of  deployment  and/or 
are  subject  to  conversion  into  reliability  improvement  warranties. 

It  is  highly  desirable  that  the  program  unit  production  cost 
goal  be  no  more  fragmented  than  necessary  to  reflect  the  actual 
development  and  procurement  structure  of  the  acquisition  program. 

/ Excessive  fragmentation  eliminates  the  management  flexibility  of 

the  program  manager.  In  the  case  of  operating  and  support  cost 
goals  these  should  normally  be  established  for  elements  of  the  sys- 
tem l;or  which  reliability,  manning,  repair,  and  spares  costs  or 
ocher  quantitative  factors  can  be  Identified. 

It  should  be  understood  that  there  will  not  necessarily  be  an 
obvious  direct  reconciliation  between  program  design  to  cost  goals 
and  contract  goals  because  some  cost  elements  included  in  program 
goals  are  not  appropriate  for  inclusion  in  contract  goals  and,  In 
some  cases,  not  all  .program  hardware  elements  will  be  reflected  in 
contract  goals.  It  should  also  be  understood  that  the  reconciliation 
between  program  unit  design  to  cost  goals  and  production  contracts 
will  he  further  complicated  by  economic  escalation  (program  goals 
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are  in  constant  dollars),  laarning  curves  and  variances  of  actual 
from  projected  production  rates  and  quantities,  and  the  fact  that 
production  contract  line  items  will  not  necessarily  align  with  DTG 
cost  elements  or  hardware  elements.  Each  Sexrvlce  has  its  own  meth- 
ods for  grouping  cost  and  hardware  elements  for  contract  line  items 
and  to  a lesser  extent  for  FYDP  and  budget  preparation.  Tlie  use  of 
DTC  managei^ent  principles  does  not  require  that  these  methods  be 
abandoned.  However,  it  does  require  that  contractual  and,  if  neces- 
sary, budgetary  provisions  be  made  to  provide  estimates  ^regarding 
the  likely  achievement  of  DTC  goals  and  also  the  actual  cost  data 
necessairy  to  verify  acccwjipllshmenc  or  the  extent  of  failure. 

A.  7 Goals  Other  Than  Average  Unit  Flyeway  Cost  Design  to  Cost 
goals  based  on  average  unit  flyaway  cost  are  most  productive  Cor 
programs  with  large  production  quantities.  Provisions  have  been 
made  in  DODD  5000.28  for  those  programs  which  do  not  meet  this  re- 
quirement to  use  cost  goals  based  on  other  cost  definltlono  included 
in  the  Budget  Guidance  Manual.  The  most  comnon  is  to  base  the  DTC 
goal  on  total  acquisition  cost  for  programs  where  production  quan- 
tities are  low.  In  the  past,  some  programs  used  total  acquisition 
cost  in  then  year  dollars,  however,  the  abnormal  escalation  of  the 
pest  few  years  has  generally  made  this  t3^e  dollar  goal  untenable 
a constant  dollar  goal  is  preferred.  The  primary  criteria  is  to 
use  a cost  definition  which  is  convenient  and  useful  for  the  PM,  is 
defined  in  the  Budget  Guidance  Manual,  and  accurately  portrays  the 
cost  structure  of  the  program. 
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5.0  FRACKING 


5.1  MAJOR  REVIEWS 

At  etch  significant  aiilestone  in  the  (Jevelopment  of  a system, 
subsystem  or  cijmponent,  progress  toward  achievefnent  of  Design  to 
Cost  goals  should  be  subjected  to  intensive  review  by  the  PM,  Ser- 
vice and  the  authority  who  established  the  goal . For  major  systems 
these  reviews  will  occur  at  lea?t  at  each  DSARC  and  more  frequently 
as  the  situation  warrants. 

These  major  milestone  reviews  are  not,  however,  sufficient  for 
proper  management  of  a system  development.  They  are  too  far  apart 
in  time  and  in  terms  of  concept  and  design  maturity. 

5.2  MANAGEMENT  REVIEWS 

Thero  is  a whole  set  of  subordinate  milestones  present  within 
each  phase  of  development  which  signal  the  con5>letion  of  some  effort 
which  yields  more  con^jlete  information  as  a basis  for  assessing 


progress. 

At  the  outset  of  each  phase,  requirements  are  established, 
refined  or  changed.  The  Design  to  Cost  goals  arc  likewise  estab- 
lished, refined  or  changed  after  evaluation. 

In  each  phase,  subsequent  to  the  establishment  of  requirements, 
the  concept  or  design  is  frozen  at  a point  which  permits  assessment 
prior  to  con^>letlon  of  hardware  for  test.  There  may  be  several 
steps  fo  a system  design  freeze,  each  of  which  will  yield  signifi- 
cant data  for  Design  to  Cost  review.  For  the  system  as  a whole, 
the  last  of  these  steps  would  be  upon  delivery  for  Government 
testing. 
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It  is  inportant  to  note  that  whatever  the  milestone  at  which 
Design  to  Cost  is  reviewed^  it  must  be  related  to  the  maturity  of 
the  concept  or  design.  A significant  measure  of  the  maturity  of  a 
design  of  a system  is  the  cost  weighted  percentage  of  parte,  com- 
ponents, subsystems  or  support  equipment  which  have  matured  to  mile- 
stones such  as:  (1)  drawings  conqileted,  (2)  hardware  fabricated, 

(3)  hardware  tested,  (4)  vendor  quotes  received.  This  data  should 
be  available  at  every  Management  Review. 

In  addition  to  the  foregoing  data  relating  to  the  maturity  of 
the  design-v  and  thus  indicating  the  validity  of  cost  estimates, 
these  management  reviews  require  fairly  extensive  new  estimates  of 
the  elements  of  cost  which  are  Included  in  the  DTC  goals  or  contract 
targets.  The  following  data  elements  of  these  new  estimates  are 
required  for  a meaningful  review: 

1.  The  Work  Breakdown  Structure  (WBS)  used  or  to  be  used  in 
production  broken  down  to  a reasonable  level  (usually  3rd  or  4th). 

2.  A current  estiraate  of  production,  operating  and  support 
cost  for  each  of  the  lowest  level  elements  of  the  WBS. 

3.  These  estimates  displayed  by  functional  cost  elements  such 
as  labor,  overhead,  purchased /subcontracted  parts,  G&A  and  Profit. 
(See  DOD  7110, IM) 

4.  A successive  smnoatlon  of  these  detailed  estimates  at  each 
level  of  the  WBS. 

5.  Identification  and  analysis  of  deficiencies  at  each  level 
between  the  current  estimate  and  prior  estimates  or  the  DTC  goal  or 
contract  target. 
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6.  Proposed  or  inplemented  actions  to  correct  over-target 
variances  or  to  take  advantage  of  under-target  conditions. 

Reliability,  availabi..i.cy  and  maintainability  reports  against 
predicted  and  allocated  growth  give  some  measure  of  operating  and 
support  cost  progress.  Conversion  to  comparative  cost  can  be 
accomplished  utilizing  cost  factors  or  cost  models. 

5.3  CONTINUING  ATTENTION 

5.3.1  In  addition  to  specific,  scheduled  reviews,  there  must  be 
constant  attention  on  the  part  of  designers,  managers  and  executives 
in  the  Government  and  Contractor,  to  what  is  happening  with  respect 
to  cost.  This  requires  that  some  means  exist  to  assess  the  cost 
lnq>act  of  eacli  and  every  design  decision  or  alternative.  These 
means  may  vary  widely  but  all  must  involve  a way  to  provide  the 
designer  with  cost  information  whicn  Is  current  and  reasonably 
accurate.  At  every  point  In  the  development  cycle,  production 
engineers,  logisticians  and  cost  analysts  must  participate  in  the 
design  process. 

5.3.2  If  a continuing  feedback  of  cost  and  design  Is  established, 

a continuing  check  on  progress  toward  DTC  goals  can  be  obtained  and 
used  by  program  managers.  Most  often,  this  continuing  check  will 
consist  of  a variance  analysis  conducted  at  specific  Intetrval.s 
(usually  quarterly)  at  significant  levels  of  the  Work  Breakdown 
Structare. 

These  checks  should  usually  display  the  then  current  estimate 
of  cost  and  compare  it  with  the  allocated  cost  goal  at  each  of  the 
lower  levels  of  the  WBS  derived  from  the  last  management  review. 
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r A ccraq)lete  new  estimate  at  the  quarterly  checks  is  not  cost  effec- 

tive and  probably  not  possible.  However,  the  key  is  the  on-going 
identification  of  suspected  variances. 

5.3.3  It  is  usually  possible  to  achieve  some  degree  of  trade-off 
of  costs  between  elements  of  the  Work  Breakdown  Structure.  Periodic 
reporting  and  tracking  requirements  should  not  constrain  the  designer 
in  taking  advantage  of  this  possibility.  It  is,  therefore,  prudent 
to  require  tracking  to  the  highest  levels  of  the  Work  Breakdown 
Structure  which  give  good  visibility  into  the  trends  of  cost  and 
design  decisions  and  which  coirrespond  to  decision  making  levels  in 
the  designing  organization.  However,  there  must  always  be  a method 
and  requirement  tc  reveal  successively  lower  levels  of  the  WBS  to 
\ trace  the  point  at  which  a variance  from  allocated  performance, 

maturity  or  cost  goals  or  specifications  has  occurred  or  may  occur. 
Additionally,  a very  costly  item  may  be  positioned  at  a relatively 
low  level  of  the  WBS  and  because  of  large  opportunities  for  cost 
variances  or  because  the  item  in  question  may  be  used  in  other  sys- 
tems, tracking  of  its  costs  and  performance  may  be  necessary. 


6.0  MANAGEMBKT 


6.1  General . Iitp lamentation  of  DTC  was  not  intended  to  require 
separate  DTC  Managers » Teams , Sections,  etc.  DTC  management  must 
be  Integrated  into  the  existing  management  systems  and  procedures 
and  must  be  the  concern  of  everyone  involved  with  the  development. 
The  use  of  cost  as  a design  criteria  and  cost  goals  for  control 
must  be  introduced  and  supported  by  the  highest  levels  of  manage^ 
ment  in  each  organizational  unit  and  permeate  the  stinjcture  just 

as  any  other  discipline  that  is  executed  by  management.  No  separate 
DTC  unit  or  team  can  successfully  implement  the  concept  from  a staff 
position. 

6.2  DTC  Management  Functions.  DTC  management  functions  are  pre- 
cisely geared  to  and  must  become  an  integral  part  of  detailed  pro- 
gram management.  The  functions  generally  breakdown  into  two  dis- 
tinct pliases  separated  by  the  establishment  of  a firm  program  DTC 
goal  by  higher  authority. 

During  concept  fornwlation  and  Advanced  Development,  the  pri- 
mary management  functions  L,re  directed  toward  identificaLion  and 
validation  of  the  system  performance,  cost  and  schedule  desired. 

DTC  management  likewise,  must  identify  and  validate  the  cost  ele- 
ments coo^osing  the  recommended  program  DTC  goal.  Continuing  iter- 
ation between  mission  requirements  and  affordability  with  the  devel- 
opment technical  solution  and  its  cost  is  needed  to  entabllsh  the 
early  technical  and  cost  objectives  for  the  development.  Tlie  thrust 
and  direction  must  be  continuously  aimed  &t  determining  the  system 
to  enter  Full  Scale  Development  and  identifying,  justifying  and 
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supporting  its  projected  average  flyaway  unit  cost  and  the  goals 
eetablished  for  O&S  cost  factors. 

Entry  into  Full  Scale  Development  (DSARC  Milestone  II,  or 
equivalent  milestone  for  lass  than  major  progrram)  selects  and 
approves  the  syt^tem  to  be  developed  and  establishes  its  average 
flyaway  unit  cost  in  the  form  of  a firm  DTC  goal.  If  the  estab- 
lished DTC  goal  differs  from  the  Program  Managers  reconmended  goal, 
it  will  be  necessary  to  review  the  entire  program  DTC  structure  and 
adjust  such  as  necessary  to  conform  to  the  firm  DTC  goal. 

The  new  firm  prog’.,vn  DTC  goal  and  the  adjusted  subgoals  now 
become  the  baseline  cost  specification  for  each  element  of  the  pro- 
gram and  the  DTC  management  functions  shift  toward  control  of  cost 
during  subsequent  development  and  production  efforts. 

6.3  Managerial  S-stem.  Because  the  DTC  goal  and  process  is  dirseted 
at  control  of  average  unit  flyaway  cost,  there  must  be  a system 
available  to  account  for  the  subelement  goals  which  comprise  the  pro- 
gram DTC  goal. 

6.3.1  Program  Managers  System.  The  program  DTC  goal  is  based  on 
the  program  cost  elements  accounted  for  at  the  Program  Managers  level. 
It  would  be  rare  for  any  single  prlxae  contractor  to  control  all  the 
costs  in  these  elements.  It  is,  therefore,  necessary  for  the  Program 
Manager  to  have  his  basic  system  controlled  within  his  office  and 
accutuilate  all  cost  elements  included  at  his  level.  Some  of  the  more 
desirable  characteristics  of  such  a system  would  Include  the  following: 

1.  Because  the  DTC  goal  is  based  on  a production  cost  element, 
the  system  must  be  keyed  to  the  programs*  production  plan,  usually 
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tVie  Production  Work  Breakdown  Structure. 

2.  The  system  must  be  integral  with  the  cost  estimating  meth- 
ods, procedures  and  process  utilized  by  the  PM  and  able  to  display 
both  the  goal  breakdown  and  comparable  current  best  estimate. 

3.  The  system  should  be  discrete  enough  to  provide  goal  visi- 
bility to  all  sube lament  managers  and  able  to  portray  cost  manage- 
ment performance  at  each  level. 

4.  All  cost  elements  required  to  be  in  the  DTC  goal  must  be 
consistent  with  the  supporting  criteria  for  the  goal  and  easily 
summed  to  program  DTC  goal. 

5.  The  system  must  be  able  to  be  adjusted  for  changes  in  pro- 
duction quantities,  rates  and  schedules,  economic  escalation,  changes 
in  funding  profiles,  etc. 

6.  The  system  should  be  structured  to  utilize  all  DTC  data 
generated  in  the  development  phases  including  contractor  and  in- 
house  inputs,  refinements,  trade-off  action,  prototype  and  cost 
model  data,  etc. 

6.4  Contractor  DTC  Management.  The  PM,  via  the  RFP  and  contract, 
must  insure  that  contractor' s management  systems  will  provide  DTC 
cost  projections  and  information  conpatible  with  his  own  management 
system.  Some  contractors  will  have  this  ability  from  their  existing 
normal  management  system  others  must  make  some  adjustments.  These 
adjustments  are  not  envisioned  to  result  in  the  establishment  of  new 


and  extensive  DTC  Management  Systems;  all  of  the  functions  required 
by  the  DTC  concept  are  now  being  accomplished  in  one  form  or  another. 
Any  adjustment  necessary  would  be  required  in  the  order,  priority. 


form  and  use  of  the  generated  information.  Some  training  may  be 
necessary^  but  this  should  be  little  more  than  would  be  necessary 
to  conduct  normal  buclnoss  in  the  comraarcial  market  place. 

The  key  elements  of  any  contractors  management  system  to  he 
examined  for  DTC  operations  included  (1)  the  contractors  methods 
for  subalvlding  and  distributing  the  contract  DTC  goal  to  his 
designers;  (2)  his  methods  of  feeding  back  production  estimates 
of  preliminary  designs  to  ti.  designers  (the  time  lapse  for  this 
operation  is  critical  varying  by  actual  industry  observation  from 
instantaneously  to  weeks);  (3)  the  methods  for  collecting  produc- 
tion estimates  on  final  designs  and  updating  the  production  cost 
projections;  (4)  methods  for  obtaining  and  integrating  sub-contract 
DTC  data. 

It  should  always  be  stressed  that,  although  the  PM  will  require 
some  DTC  data  from  the  contractor,  the  contractors  management  sys- 
tems must  produce  the  above  type  information  for  his  own  internal 
cost  control,  if  he  intends  to  successfully  compete  in  business  in 
a Design  to  Cost  atmosphere'. 


7.0  CONTRACTUAL  IMPLEMENTATION  OF  DESIGN  TO  COST 

7.1  OBJECTIVES 

7.1.1  Contracting  for  the  Various  Program  Phases.  Most  prograjms 
which  have  design  to  cost  goals  will  go  through  four  distinct  con- 
tractual phases:  (1)  the  conceptual  phase,  which  will  consist  of 
In-house  and  contractor  studies;  (2)  the  validation  or  advanced 
development  phase,  which  will  norr.ially  entail  the  contractor  design, 
fabrication  and  test  of  one  or  more  complete  or  partial  prototypes 
of  the  system;  (j)  the  full-scale  development  phase  which  will  in- 
clude the  con?)lete  contractor  design,  fabrication  and  test  of  one 
or  more  production-configuration  systems,  and,  finally,  (4)  the 
production  phase  which  will  include  the  contract(s)  for  series  pro- 
duction of  the  required  quantity  of  systems.  Where  funding  is 
available,  the  conceptual,  validation  and  the  full-scale  development 
phase  may  Involve  contractors  operating  in  parallel.  Contracts  for 
these  phases  should  be  of  types  consistent  with  the  technical  and 
other  risks  associated  with  the  program.  During  the  production 
phase,  the  Government  may  exercise  options  for  reliability  improve- 
ment warranties.  Of  course,  the  agreement  on  contract  type  is  a 
bilateral  contracting  decision  which  will  be  influenced  by  the 
particulars  of  each  individual  procurement  situation.  The  produc- 
tion phase  may  also  involve  competitive  procurement,  based  prin- 
cipally on  price,  commencing  as  early  as  the  first  quantity  produc- 
tion contract;  or  a second  source  production  contractor  may  be 
developed.  Contracting  for  Design  to  Cost  is  discussed  in  subse- 
quent paragraphs. 


7.1.2  Procurement  Objectlvea.  The  basic  objectives  in  contracting 
for  a Design  to  Cost  program  eret 

1.  To  define  Design  to  Cost  targets  in  terms  which  are  au- 
ditable, contractually  enforceable,  and  meaningful  to  both  the  con- 
tractor and  the  Government.  Note  that  contract  provisions  nortoally 
use  '‘target”  and  management  documents  utilize  the  broader  term 
"goal.” 

2.  To  contractually  establish  the  schedule  for  contract 
performance  and  the  requirements  for  contract  deliverable  'end-item 
performance  and  configuration  in  the  scope  and  depth  necessary  to 
protect  the  interests  of  the  Government  and  provide  for  an  enforce- 
able contract,  yet  allow  the  contractor  latitude  to  tailor  his  de- 
sign to  fit  design  to  cost  targets. 

3.  To  define  the  means  by  which  contractor  progress  towards 
design  to  cost  targets  will  be  formally  assessed,  recorded  and 
reportel. 

4.  To  provide  incentives  which  will  effectively  motivate  the 
contractor  to  exert  himself  to  achieve  the  design  to  cost  targets. 

7.2  CONCEPTUAL  PHASE 

7.2.1  Contract  Requirements.  The  contracts  in  this  phase  are  typ- 
ically for  studies  and/or  feasibility  models.  At  this  stage,  often 
there  is  no  formal  requirement  for  a program  design  to  cost  target. 
However,  in  some  cases  the  contractorf  s)  may  be  provided  guidance 
as  to  the  anticipated  acceptably  cost  level  along  with  other  design 
guidsnoo.  Where  this  is  done  the  guidance  should  be  in  sufficient 
detail  to  be  meaningful,  l.e.,  the  Included  planned  elements  of 
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coit  and  the  general  production  quantities  and  rates  and  deployment 
concept. 

7.2.2  Outputs.  One  of  the  outputs  of  the  conceptual  phase  should 
be  information  sufficient  to  establish  the  system  design  to  cost 
goals  and  targets  vrith  a reasonable  level  of  confidence.  Therefore, 
the  requirement  to  make  any  guidance  regarding  costs  meaningful  to 
the  contracting  parties  also  applies  to  any  estimate  of  unit  produc- 
tion cost  and  operating  and  support  cost  required  from  the  contrac- 
tor as  a product  of  his  study.  Estimates  should  be  required  to  be 
in  as  much  detail  and  with  as  much  substantiating  data  as  is  con- 
sistent with  the  degree  of  design  definition.  One  of  the  objectives 
of  the  studies  of  the  conceptual  phase  should  be  an  appreciation  on 
the  part  of  the  procuring  activl.ty  as  to  what  performance  and  logis- 
tics support  levels  can  be  obtained  within  design  to  cost  goals. 

7.3  VALIDATION  FPJhSE 

7.3.1  Request  for  Proposal  (RFP).  This  phase  may  involve  prototype 
design,  fabrication,  and  test.  Often  there  is  corpetitlon  among  two 
or  more  contractors  when  program  unding  considerations  permit.  This 
also  likely  will  be  the  first  phase  in  which  desigt.  to  cost  targets 
will  be  contractually  specified.  In  this  phase,  the  RFP  should 
specify  design  to  cost  targets  or  affordability  ceilings  and  the 
minimum  acceptable  performance  and  schedule  constraints.  In  spec- 
ifying the  performance  and  other  design  requirements,  great  care 
should  be  exercised  to  avoid  the  inclusion  of  requirements  which 
would  have  significant  cost  but  make  only  a marginal  contribution 
to  accoiopllsfament  of  the  required  mission,  or  which  add  to  life 


cycle  cost  out  of  proportion  to  their  contribution  to  syste-u  -sissi^.-: 
effectiveness. 

7.3.2  RFP  Considerations.  The  contractor  should  be  asked  to  pro- 
pose a design  and  a program  for  achieving  that  design  which  he  con- 
siders to  be  a balance  among  performancet  life  cycle  cost  elements 
and  schedule.  Uhen  pertinent  life  cycle  cost  models  are  available^ 
consideration  should  be  given  to  utilizing  the  RFP  to  make  them 
available  to  prospective  offerors.  The  RFP  requirements  should  be 
structured  to  encourage  the  offerc.-s  to  exercise  technological  inr 
genuity  and  inventiveness  in  their  proposal.  Therefore,  detail 
specifications  and  technical  requirements  which  are  not  essential 
to  the  advance  development  phase  should  be  excluded.  The  RFP  should 


concentrate  on  the  system  capabilities  essential  to  mission  accom- 
plishment and  the  reliability  and  maintainability  characteristics 
necessary  for  efficient  deployment  and  operation.  It  may  be  that 
the  advance  development  models  of  the  system  will  not  be  required 
to  demonstrate  all  of  these  characteristics;  however,  to  the  extent 
they  are  known,  the  RFP  for  the  advance  development  phase  should 
specify  the  essential  requirements  to  be  met  by  the  fully  developed 
system.  Consideration  should  be  given  to  stating  the  performance 
requirements  in  terms  of  one  or  more  tnlssion  scenarios,  with  the 
offerors  required  to  propose  a system  capable  of  performing  the 
xalssion(s)  described.  The  RFP  should  specify  the  relative  impor- 
tance for  the  various  items  of  performance:  cost,  design  charac- 
teristics, and  fjchedule.  This  will  facilitate  the  offerors  proposing 
designs  which  achieve  the  desired  balance  among  these  features.  In 
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validation,  particularly  where  there  is  competition,  this  ranklnjj 
of  paratoeters  should  be  continued  in  the  contract  for  the  purpose 
of  accommodating  trade-offs  during  the  development  of  the  design. 
Even  in  the  absence  of  such  ranking,  the  RTF  and  contract  must 
specifically  descrioe  what  may  be  traded  by  the  contractor  and  what 
trades  require  Government  approval. 

Design  requirements  may  be  specified  in  terms  of  compatibility 
with  equipments  and  facilities  with  which  the  system  must  operate. 
The  offerors  should  be  encouraged  to  identify  levels  or  types  of 
performance  which  they  consider  to  be  hlg’t  risk  and/or  likely  to 
have  a predcmlnant  effect  on  life  cycle  cost.  This  can  be  done 
directly,  or  by  requiring  the  offerors  to  state  and  rationalize 
levels  of  confidence  of  achieving  various  levels  of  performance 
within  design  to  cost  targets,  or  by  other  appropriate  means. 

In  this  phase,  the  degree  of  latitude  given  the  offerors/con- 
tractors  will  be  heavily  Influenced  by  the  degree  of  competition 
maintained.  Where  funding  constraints  necessitate  the  Sv'ilection 


of  only  a single  advanced  development  contractor,  the  proper  pro- 
tection of  the  Government’s  interest  may  require  somewhat  less  flex- 
ibility in  the  RFP  and  subsequent  contract  requirements.  Howevvsr, 
the  article  developed  in  this  phase,  barring  significant  design 
changes,  will  largely  determine  life  cycle  cost;  therefore,  the 
basic  guideline  to  be  followed  in  all  cases  is  to  avoid  unnecessary 
requirements  and  allow  latitude  of  design  to  fit  the  cost.  The  dv*- 
sign  to  cost  requirement  must  be  stated  in  meaningful  and  specific 
tcimis,  based  upon  quantities,  rates  and  time  periods  involved  and 
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■ deployroent  concept.  Alio,  the  coet  elements  included  In  design 
to  cost  targets  must  be  clearly  specified.  If  ceilings  or  other 
limiting  goals  are  to  be  placed  on  other  elements  of  cost,  this 
too,  must  be  clearly  specified. 

7.3.3  Proposal  Evaluation.  The  implementation  of  a design  to  cost 

requirement  places  an  extra  burden  on  the  DOD  source  selection  pro- 
cess. In  selecting  the  validation  contractor(s)  it  is  necessary  to 
identify  the  proposal(s)  which  offer  the  best  potential  combination 
of  performance  and  life  cycle  cost.  To  do  this,  it  is  necessary  to 
evaluate  the  proposed  technical  approaches  and  to  establish  the 
credibility  of  each  offeror's  production,  operating  and  support  cost 
eatimatos.  The  selection  may  be  complicated  by  the  existence  of 
different  designs  and  technical  approaches  among  the  various  pro- 
posals as  a result  of  the  flexibility  allowed  in  this  phase.  | 

f 

7.3.4  Proposal  Requirements.  In  order  to  clarify  the  Government's 
objectives,  siiqplify  proposal  preparation,  and  ease  the  proposal 
evaluation  task,  the  principal  source  selection  criteria  should  be 
included  in  the  RFP.  These  should  direct  the  offerors’  efforts  to 
what  the  procuring  activity  considers  to  be  the  most  iiqportant  areas 
of  performance,  design,  schedule,  risk  and  cost.  The  RFP  should 
pro^riLde  guidance  as  to  the  scope  and  depth  of  data  required  to  sup- 
port all  claims  made  in  the  proposal.  In  the  cost  area,  each  offeror 
should  be  required  to  provide  estla'ates  of  production,  operating  and 
support  costs  of  his  design.  Each  offeror  should  describe  in  his 
proposal,  the  methodology  used  to  generate  the  estimate,  the  assump- 


tions made,  the  data  used  and  their  sources.  Estimates  of  the 
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program  costs  not  Included  within  design  to  cost  targets  may  also 
be  required  if  they  are  a significant  part  of  the  estimated  total 
progra®  cost. 

7.3.5  Contract  Requirements  for  Design  to  Cost.  The  advance  devel- 
opment contractCs)  should  specify  the  design  to  cost  targets,  the 
cost  elements  Included  In  them  including  any  escalation  factor  used, 
production  planning  and  deployment  concept  on  which  the  design  to 
cost  targets  are  based,  requirements  for  tracking  and  reporting 
status  against  the  targets,  and  the  data  required  at  contract  com> 
pletlon  to  verify  design  to  cost  accomplishment.  Requirements  for 
any  planned  DOD  reviews  of  these  cost  estimates  should  also  be 
specified. 

In  the  technical  area,  contract  requirements  should  follow  the 
philosophy  expressed  regarding  those  requirements,  i.e.,  contract 
requirements  should  concentrate  on  the  kinds  and  levels  of  perform- 
ance essential  to  mission  accon^>llshment.  Nonessential  and  hlgblyy 
detailed  requirements  should  be  avoided.  The  contract(s)  should 
define  as  system  requirements 'only  those  necessary  for  mission  capa- 
bility and  compatibility  with  other  DOD  equipments  and  facilities. 

7.3.6  Contractor  Latitude  for  Trade-Offs.  During  advance  develop- 
ment, the  contractor  should  be  given  broad  latitude  to  make  trade- 
offs between  performance  and  cost  In  order  i:o  achieve  the  design  to 
cost  objective.  These  trade-offs  are  of  two  major  tyfies:  those 
which  affect  design  within  the  specified  performance,  production 
plan,  deployment  concept,  cost  and  schedule,  and  those  which  require 
changes  to  these  specified  parameters.  As  to  the  first  type,  the 
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contractor  should  be  allowed  complete  freedom  of  decision  without 
Oo\'ernment  Involvement  (except  for  visibility).  While  the  second 
type  roust  be  a decision  of  the  Governspcnt,  the  contractor  should 
be  strongly  encouraged  to  challenge  the  specified  parameters  and 
recommend  changes  to  them  wherever  there  is  a valid  Indication  of 
significant  cost  savings.  This  latter  effort  can  be  especially  pro- 
ductive in  examining  trade-offs  between  production,  operating  and 
support  costs.  Any  use  of  Value  Engineering  contract  provisions 
should  be  tailored  to  ensure  compatibility  with  the  design  to  cost 
requirements. 

7.3.7  Contract  Incentives  and  Goapetition.  It  is  probably  unneces- 
sary to  utilize  incentives  to  motivate  achievement  of  design  to  cost 
targets  in  advance  developn^nt  contracts  when  competition  is  main- 
tained throughout  this  phase.  Conq>etitlon  is  likely  to  be  a much 
more  effective  spur  to  achievement  of  the  design  to  cost  targets 
than  any  cost  incentive.  Therefore,  contractual  Incentives  are 
likely  to  be  ineffective  when  con5>etltlon  is  present.  However,  if 
there  is  only  a single  system  contractor  during  this  phase,  it  may 
be  desirable  to  use  contract  incentives.  In  validation,  the  most 
flexible  Incentive  would  be  an  award  fee.  Award  Fees  can  be  devel- 
oped to  permit  an  appraisal  (with  associated  fee  awards)  of  the 
overall  performance  of  the  contractor  in  balancing  performance,  cost 
and  schedule. 

7.3.8  Subcontractors . Most  major  defense  system  developments  en- 
tail work  by  one  or  more  major  subcontractors  as  well  as  the  prime 
contractor.  Frequently  the  subcontractor  Is  responsible  for  a 
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portion  of  the  fiystem/aubaystem  which  is  critical  to  system  per- 
formance and  constitutes  a substantial  part  of  total  system  costs, 
under  these  circumstances,  it  may  be  necessary  for  the  primce  con- 
tract(s)  to  require  the  allocation  of  design  to  cost  targets  to 
such  subcontracts.  The  tracking  and  reporting  of  progress  toward 
these  targets,  and  visibility  of  prime  contractor  decisions  re- 
garding changes  (trade-offs)  in  subcontract  design  to  cost  targets 
and  performance  requirements  should  be  Included. 

7.4  FULL-SCALE  DEVELOPMENT  PHASE 

7.4.1  Contractor  Selection.  By  the  time  the  program  enters  this 
phase,  the  design  configuration  and  the  system  performance  require- 
mentt  should  be  established  except  for  relatively  minor  modifica- 
tions. When  parallel  full-scale  development  is  not  feasible,  source 
selection  for  this  phase  involves  the  selection  of  the  better  ad- 
vance development  design  in  terms  of  system  performance,  cost  and 
schedule.  Since  advance  development  for  all  except  the  most  costly 
systems  will  entail  the  testing  of  prototypies,  there  will  normally 
be  test  data  upon  which  to  base  the  evaluation  of  performance  and, 
to  a lesser  extent,  operating  and  support  cost.  The  actual  costs 
incurred  in  prototype  fabrication  may  provide  a useful,  but  not 
conclusive,  indication  of  the  production  unit  costs.  The  advance 
development  contractor(s)  should  be  required  to  provide  refined 
estimates  of  production,  operating  and  support  cost.  Methodology, 
plans,  assuoptions,  data  and  source  information  should  be  made 
available  by  the  contractor  and  reviewed  by  the  source  selection 
authority  and/or  his  representatives.  The  review  and  evaluation 
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nomally  will  be  more  lnte\.slve  than  that  conducted  during  advance 
development  because  of  the  greater  quantity  and  accuracy  of  data 
available. 

7.4.2  Contract  Technical  Requirements.  Because  the  full-scale 
development  phase  will  often  have  a single  contractor  for  the  system, 
the  contract  requirements  will  normally  be  more  explicit,  'rhls  Is 
also  consistent  with  the  degree  of  system  definition,  since  by  this 
phase,  design  configuration  and  performance  normally  should  be  es- 
tablished and  reflected  in  the  contract  requirements.  However,  as 
with  advance  development,  unessential  and  overly  detailed  technical 
requirements  should  be  avoided. 

'’Trade-Offs,  ilie  full-scale  development  phase  normally  will 
not  be  characterized  by  major  cost  and  performance  trade-offs  unless 
problems  arise  which  invalidate  the  conclusions  of  the  advance  de- 
velopment phase.  Trade-off  flexibility  must  still,  however,  exist 
between  DTC  goals  and  artlcipated  life  cycle  costs  where  significant 
life  cycle  cost  savings  can  be  demonstrated.  Any  decision  regarding 
trade-offs  "which  affect  system  level  configuration,  performance  and 
life  cycle  costs  are  likely  to  Involve  significant  re-orientation 
of  the  development  program  and  should  be  made  by  the  DOD  program 
manager  or  higher  levels  if  DCP  goals  are  affected.  Contractor  de- 
cisions in  full-scale  development  are  likely  to  be  limited  to  the 
selection  of  detailed  design  alternatives. 

7.4.4  Contract  Design  to  Cost  Requirements.  The  full-scale  devel- 
opment contract  must  include  design  to  cost  targets,  a definition 
of  the  cost  elements  included,  and  the  assuiqptlons  upon  which  the 
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targets  arc  predicated.  The  contract  should  also  .nclude  the  re- 
quirements for  the  tracking,  reporting  and  review  of  status  with 
respect  to  these  targets.  Provlsiors  covering  the  allocation  of 
targets  to  the  major  subcontractor(s)  and  tne  tracking,  reporting 
and  review  of  their  status  should  also  be  iticluded. 

The  unit  production  cost  tai'get  Included  In  the  fcll-scale 
development  contract  should  be  defined  In  terms  that  enable  the  use 
of  contractor's  cost  accounting  system  or  elaments  which  are  cilrectly 
relatable  to  those  of  his  system.  This  establishes  a basis  for  di- 
rect comparison  of  contractor  estimates  and  actuals  with  the  con- 
tract target.  Since  pperating  and  support  cost  targets  or  tactors 
may  take  many  forms,  the  definition  of  the  elements  must  be  accom- 
plished on  an  individual  basis.  Tlie  dufinitions,  however,  must  be 
consistent  with  the  elements  of  data  to  be  collected  during  opera- 
tional test  and  evaluation. 

7.4.5  Design  to  Cost  Contract  Incentives.  The  contract  should  be 
structured  to  require  and  motivate  the  contractor  to  introduce  pro- 
ducibility  and  supportabillty  considerations  into  his  design,  suggest 
configuration  changes  which  can  reduce  cost  without  seriously  re- 
ducing mission  performance  capabilities,  and  to  recommend  the  elim- 
ination of  performance  requirements  or  specifications  which  he  con- 
siders to  be  unproductive ly  costly;  l.e.,  do  not  provide  system 
capabilities  commensurate  with  their  costs.  Since  the  full-scale 
development  pha«e  usually  does  not  involve  parallel  contracts,  it 
is  in  this  phase  that  maximum  consideration  should  be  given  to  con- 
tractual means  of  motivating  achievements  of  DTC  targets.  The 
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success  or  failure  in  the  achievement  of  the  targets  will  be  largely 
determined  by  the  basic  design  configuration  defined  in  advance  de- 
velopment. In  full-scaie  developtiient,  the  significant  challenges 
are  avoidance  of  coat  increases  through  introduction  of  changes  and 
proper  consideration  of  producibility  and  supportabllity.  Where 
competition  does  not  exist,  additional  incentives  may  be  the  appro- 
priate means  to  motivate  the  contractor  to  apply  the  kind  of  effort 
needed  to  do  the  coir^jlex  job  necessary  in  designing  to  life  cycle 
cost. 

7.4.6  'iVpes  of  Incentives.  The  nature  of  the  incentive  arrangement 
and  the  size  of  the  Incentive  should  be  determined  on  the  basis  of 
its  purpose  in  the  overall  •'cquisition  strategy.  If  the  strategy  is 
to  rely  primarily  upon  coti?.v.i:ltlon  and  trade-offs  in  the  advanced 
and  full-scale  development  phase  to  achieve  the  DTC  targets,  then 
the  use  of  DTC  incentives  will  normally  be  unwarranted.  If  compe- 
tition does  not  exist,  then  the  contract  should  contain  some  type 
of  incentive  to  properly  motivate  the  contractor  to  achieve  the  de- 
sign to  coat  target.  One  such  arrangejnent  would  be  an  award  fee 
(as  an  additional  incentive  in  the  development  contract,  (for  exam- 
ple, CPIF/AF)).  Because  of  the  conq)lexity  inherent  in  the  nature  of 
operating  and  support  (O&S)  targets  and  their  measurement,  the  flex- 
ibility of  an  award  fee  arrangement  is  particularly  useful  for  O&S 
cost  incentives.  However,  an  award  fee  is  not  S fee  to  which  the 
contractor  is  automatically  entitled  by  achievement  to  a single 
objective.  Determining  and  awarding  the  amount  or  amounts  of  fee 
rests  with  the  Government  alone.  If  the  amount  or  amounts  were 
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specific,  entltleroents  to  the  contractor  upon  achievement  of  the 
specified  carget  alone » these  sums  would  be  included  within  the 
inceiitive  pattern  of  a firtoar  type  contracts  e.g.s  CPIF.  The  Gov- 
ernment may,  under  an  award  fee  contract,  properly  not  award  any 
stuns  specified  as  award  fee,  if  the  contractor  has  achieved  the 
single  objective  while  performing  at  unacceptable  levels  under 
other  key  elements  of  the  contract.  Predetermined  milestones  should 
be  established  where  increments  of  award  fees  may  be  paid.  Incre- 
ments to  be  paid  should  be  a smaller  percentage  of  the  total  award 
fee  at  the  initial  milestones  and  become  larger  towards  the  end  of 
the  contractual  effort.  These  interim  evaluation  features  will  in- 
still a discipline  periodic  examination  of  progress  against  the  de- 
slng  to  cost  targets.  Incentive  arrangements  providing  for  penalties 
for  missed  targets  also  should  be  used  whenever  appropriate. 

A second  alternative,  particularly  for  production  cost  targets, 
is  a variation  of  the  fixed  price  incentive  foxmiula  (FPI)  type  of 
contract.  Under  this  arrangement,  development  could  be  performed 
under  cost- type  contracts,  but  with  an  agreed  upon  formula  for  es- 
tablishing the  profit  of  at  least  the  initial  major  production  con- 
tract. This  formula  would  base  the  target  profit  of  the  production 
contract  on  the  achievements  in  regard  to  the  design  to  cost  target 
and  the  required  performance  in  the  development  contract.  The  for- 
mula would  reward  the  contractor  with  a substantial  Incentive  pay- 
ment if  he  were  able  to  achieve  or  beat  the  design  to  cost  target 
contained  in  the  full-scale  development  contract  (and  in  the  sub- 
sequent production  contract)  without  degrading  system  perfoxnnance 
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below  required  levels.  In  this  situation,  the  formula  should  relate 
the  cumulative  average  unit  production  cost  en?>loyed  as  the  overall 
design  to  cost  target  to  the  cumulative  average  cost  for  the  number 
of  units  to  be  procured  under  the  production  contract(s)  to  which 
it  is  to  bo  applied.  This  approach  also  could  provide  for  penalties 
if  the  contractor  did  not  meet  the  design  to  cost  target. 

In  those  instances  where  a substantial  fee  may  be  paid  by  the 
Government,  the  basis  of  an  estimate  or  projection  should  be  devel- 
oped in  accordance  with  an  agreed  fonrcila.  The  formula  should  pro- 
vide for  such  matters  as  application  of  progress  (learning)  curves, 
the  effects  of  hard  tooling,  rate  tooling,  labor  mix  changes,  for- 
ward pricing  rates,  and  adjustments  for  inflation.  Any  other  fac- 
tors of  sl^snificance  to  the  program  should  also  be  addressed.  A 
fonoila  treatment  of  this  type  is  best  suited  to  programs  with  a 
low- rate  production  phase. 

Powerful  motivation  for  the  control  of  unit  production  costs 
in  full-scale  development  can  be  achieved  through  the  use  of  a 
priced  option  for  initial  produc*-^on  quantities  in  the  development 
contract.  This  approach  is  scrictly  limited  by  DOD  Directive  5000.1 
to  those  cases  in  which  risks  have  been  reduced  to  manageable  levels. 
7.4.7  Reliability  Improvement  Warranties  (RIW).  The  use  of  reli- 
ability Improvement  warranties  (RIW)  on  selected  hardware  can  pro- 
vide additional  teotlvation  to  the  contractor( s)  to  consider  opera- 
tional supportability  factors  during  the  design  and  development 
process.  Decisions  fo*:  RIW  application  should  be  made  as  early  as 
possible  in  the  acquisition  cycle.  The  contractor  should  be  Informed 


early  in  the  design  phase  that  there  will  be  warranty  requirements 
so  that  reliability  and  maintainability  are  given  appropriate  atten- 
tion at  the  time  the  equipment  is  initially  designed. 


It  should  be  enphasized  that  the  terms  and  conmltments  required 
of  the  contractor  should  result  in  a reasonable  balance  between  his 
risk  and  the  degree  of  incentive  needed  to  achieve  the  prixaary  goal 
of  system  availability.  The  size  and  scope  of  the  initial  commit- 
ment should  be  determined  in  consideration  of  the  uncertainties  and 
future  support  cost  and  the  risk  Involved  to  both  contractor  and 
Government . 

7.4.8  Cost  Reduction  Contract  Changes.  In  design  to  cost,  it  is 
DOD  policy  t’o  encourage  contractor- generated  contract  cost  reduction 
change  proposals  which  identify  unnecessary  or  marginally  cost- 
effective  specifications  and  requirements.  Historically  development 
contracts  have  generally  been  silent  in  this  regard. 

There  are  several  ways  to  treat  this  problem  contractually. 

One  is  to  treat  such  proposals  individually,  consistent  with  design 
to  cost  objectives.  Another  is  to  use  special  contractual  language 
addressing  this  issue.  This  could  include  incentives,  since  unless 
specifically  addressed,  DTC  production  unit  cost  or  O&S  cost  incen- 
tives do  not  address  contract  changes.  Value  Engineering  Incentive 
clauses  provide  a full  range  of  contractor  incentives  to  suggest 
such  changes  and  should  receive  serious  consideration  for  this  pur- 
pose. Several  methods  are  available  to  insure  that  VE  and  DTC  unit 
production  cost  or  O&S  cost  incentives  Interface  properly. 
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7.5  PRODUCTION  PHASE 


7.5.1  Contract  Requlretuents.  If  the  production  contracts  are 
structured  to  reward  the  contractor  for  actual  cost  perforroance 
against  the  unit  production  design  to  cost  target,  provisions  should 
be  included  (a)  to  provide  for  measwrement  of  actual  costs  against 
a target  established  in  accordance  with  an  agreed  set  of  cost  ele- 
loents  and  progress  (learning)  curves  and  (b)  to  prevent  assignment 
of  production  related  costs  to  elements  of  cost  not  covered  by  the 
design  to  cost  target.  An  approach  to  achievejnant  of  the  first  ob- 
jective is  to  express  the  dei.^  ooac  In  tersiis  cf  the  aporoprlate 

eletaents  of  the  contractor’s  cost  account «s  r^intlcned 
above,  and,  using  agreed  to  progress  (learning)  cur-»Gs 
tion  factors,  translate  the  oesign  to  cost  goal  into  numbers  a^jainst 
which  the  actual  costs  incurred  can  be  directly  measured.  To  achieve 
the  second  objective,  production  contract  activities  on  deliverable 
items  which  are  not  a part  of  the  unit  production  tasks  covered  by 
the  unit  production  cost  goal  should  be  separately  priced  contract 
line  Items  with  the  contractor  required  to  segregate  the  actual  re- 
turn costs  against  these  tasks.  These  line  Items  may  also  be  covered 
by  cost  incentive  arrangements.  The  contractor  should  be  required  to 
collect  and  periodically  report  the  actual  costs  incuxnred  in  the  ele- 
ments of  cost  included  in  the  cumulative  average  unit  production  cost 
goal.  This  will  enable  measurement  of  the  extent  to  which  the  design 
to  cost  target  is  being  achieved. 

When  the  RIW  commitment  approach  hua  been  used  in  the  develop- 
ment contract,  the  warranty  will  apply  to  production  items.  Therefore, 
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the  production  contract  ntust  provide  quantities,  rates  and  schedules 
consistent  with  the  terms  of  the  warranty. 

7.5.2  Production  Competition.  If  follow-on  production  contracts 
are  awarded  on  the  basis  of  price  competition  or  if  a second  produc- 
tion source  is  established,  the  development  and  initial  production 
contractor(s)  cannot  be  penalized  foi“  failure  of  other  contractors 
to  achieve  the  cumulative  average  unit  production  cost  goal.  In 
this  situation  there  are  too  many  factors  for  which  the  design  con- 
tractor cannot  be  held  responsible,  such  as  labor  and  overhead  rates 
and  efficiency  of  the  subsequent  producers. 

7.5.3  Design  to  Cost  and  Cost  Reduction  During  Production.  DOD 
Directive  5000.28  requires  that  production  cost  be  rigorously  con- 
trolled to  the  DTC  production  unit  cost  goals.  A number  of  factors 
such  as  engineering  fixes,  mission  changes,  and  performance  increases 
may  Increase  costs  during  production.  There  are  a number  of  tech- 
niques available  to  counter  such  Increases.  These  include  VE  Incen- 
tive clauses  and  cost  reduction  oriented  contractual  Product  Iiqjrove- 
ment  Programs.  Funding  set-asides  to  finance  such  efforts  must  be 
made  if  these  opportunities  are  to  be  properly  exploited. 
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APPENDIX  A 


GUIDELINES  FOR  UNIFORM  DESIGN  TO  COST  STATUS  REPORTING 
DURING  DEVELOPMENT 

This  appendix  to  the  JLC  Design  to  Cost  Guide  is  designed  to 
provide  guidance  and  standardization,  where,  practicable,  for  tracking 
DTC  goals  during  the  development  phase  of  a major  weapons  system 
acquisition.  Guidance  provided  is  to  assist  the  Project/  Program 
Manager  to  establish  a method  of  tracking  contractor  progress  in 
the  achievement  of  the  DTC  goal  for  the  system  being  developed  and 
produced.  Indus  , of  this  information  as  an  appendix  is  considered 
appropriate  since  there  is  no  intent  to  establish  a new  report. 

An  essential  element  in  the  management  of  a DTC  acquisition 
program  is  a system  to  faeditate  DOD  tracking  and  monitoring  of  the 
contractor's  progress  in  developing  a hardware  system  which  will  meet 
the  contractually  required  DTC  goals.  The  system  must  del  .-.sr  data  at 
a level  of  detail  which  provides  the  Government  acquisition  management 
with  meaningful  DTC  status.  Identifying  those  critical  areas  and 
problems  which  might  cause  DTC  goals  to  be  exceeded. 

It  is  emphasized  that  the  reporting  from  the  contractor  to  the  DOD 
acquisition  manager  is  only  one  element  of  the  inlornation  system 
necessary  to  effectively  execute  a DTC  development  program.  The 
contractor  must  provide  for  the  assignment  or  allocation  of  contract 
DTC  goals  to  appropriate  elements  oi  the  defense  system  on  a rational 
basis  consistent  with  system  complexity,  performance  requirements, 
schedules,  and  anticipated  costs.  Design  responsibility  for  these 
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elements  must  include  all  design  requirements  Including  DTC  goals.  As 
design  development  proceeds  the  contractor  must  estimate  Che  produc- 
tion costs  and  other  relevant  costs  of  each  projected  design  configu- 
ration, compare  it  with  the  applicable  DTC  goals  and,  whenever  neces- 
sary and  possible,  adjust  Che  design,  to  achieve  the  cost  (and 
performance)  goals. 

The  DTC  reporting  guidelines  are  separate  from  but  compatible  with 
the  cost,  schedule,  and  performance  controls  associated  with  the 
on-going  development  contract  and  provide  the  DOD  project/program 
manager  with  data  he  needs  to,  (a)  assess  how  effectively  the  contrac- 
tor is  implementing  the  DTC  program;  (b)  evaluate  DTC  goals  and 
monitor  their  projected  achievement;  (c)  perform  analysis  needed  to 
formulate  management  decisions  concerning  design  and  cost,  schedule, 
and  performance  tradeoffs;  and  (d)  use  as  an  input  into  required  cost 
reporting  to  higher  management  levels. 

Information  contained  on  page  63  establishes  DTC  reporting  guide- 
lines that  should  be  applied  to  all  projects/programs  requiring 
contractor  DTC  data.  Each  project/program  manager  must  review  the 
requirements  of  his  specific  program  and  determine  what  data  he  may 
require.  The  lcvel(s)  of  system  breakdown  and  cost  element  detail 
should  be  limited  to  those  necessary  to  provide  practical  and  useful 
data  to  the  project/program  management  office. 

It  is  important  that  a consistent  framework  be  used  throughout  the 
development  and  production  phases  for  DTC  tracking  and  reporting.  The 
contract  work  breakdown  structure  (CWBS)  normally  provides  the  neces- 


sary hardware  identification  uniformity;  and  the  cost  elements  as 
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Identified  in  Format  A on  page  6A  are  intended  to  provide  consistency 
within  a given  program  and  also  among  all  DOD  components.  Contractual 
DTC  goals  are  normally  established  by  the  project/program  manager  at  a 
summary  level.  The  contractor  then  extends  this  to  lower  levels  of 
hardware  element-*;  which  are  assigned  to  engineering  managers  or 
design  groups.  The  DTC  goals  are  allocated  to  these  elements  as  part 
of  the  design  requirements.  Normally,  it  will  be  at  this  level  that 
the  contractor  manages  the  development  of  the  system  and  tracks  and 
controls  the  achievement  of  the  DTC  goals.  Estimated  costs  of  the 
designs  for  the  hardware  elements  will  be  generated  and  fed  back  to 
the  responsible  contractor  design  managers  as  the  system  is  developed. 
Comparison  of  these  estimates  with  the  allocated  goals  will  identify 
the  cost  status  of  the  design  for  the  various  hardware  elements.  In 
any  development  program,  it  is  normal  to  expect  some  deviations  from 
original  DTC  goals  as  allocated  to  elements  in  these  lower  levels  of 
che  CWBS.  Some  of  these  deviations  may  be  higher  and  some  lower.  It 
is  not  the  primary  intent  of  DOD  to  require  contractor  efforts  to  be 
directed  toward  maintaining  these  original  lower  level  estimates 
across  the  board.  Rather,  what  is  important  is  that  the  contractor 
management  strive  to  balance  these  lower  levv■^l  costs  in  a manner  such 
that  the  aggregate  or  end-product  costs  of  the  overall  defense  sysrem 
conform  to  contract  DTC  goals  and  that  the  necessary  performance  is 
achieved.  The  key  question  is  whether  projected  program  costs  are 
within  planned  limits. 
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In  compiling  DTC  status  information  for  DOD,  therefore,  the 
essential  element  which  must  be  presented  clearly  and  prominently  is  a 
comparison  between  DTC  goals  and  current  estinvites  of  costs  for  the 
overall  end-product  defense  system  and  major  components  thereof. 

Major  component  (sub-system)  estimates  must  be  supported  by  summaries 
of  DTC  estimates  for  key  elements  in  the  next  level  or  so  of  the  CWBS. 
Any  DTC  estimate  tracking  system  must  clearly  list  and  define  all  the 
assumptions  that  were  used  to  establish  the  DTC  goal.  For  establish- 
ing design  to  unit  production  cost  goals,,  this  would  include  quantity, 
production  rate,  learning  curves,  escalation  indices  used,  production 
start  dates,  and  first  unit  costs.  Any  changes  in  assumptions  must  be 
documented  and  reflected  in  both  goals  and  estimates. 

If  the  overall  estimates  exceed  DTC  goals,  the  management  infor- 
mation system  must  provide  an  assessment  of  the  cause  and  significance 
thereof  and  a discussion  of  measures  in  process,  or  possible,  for 
bringing  them  back  within  limits.  Any  associated  performance  penal- 
ties must  be  identified. 

In  the  sense  just  discussed,  contractor  DTC  status  reporting  to 
the  project/program  manager  should  normally  be  at  contract  WBS  level 
3.  Lower  levels  of  reporting  may  be  required  by  the  Program  Manager 
as  necessary  to  track  the  status  of  critical  system  elements.  Summa- 
rization from  the  CWBS  into  the  project  summary  WBS  will  allow  project/ 
program  managers  to  relate  the  current  contract  DTC  estimates  to  the 
DTC  goals  for  the  total  program. 


Formats  A and  B have  been  developed  to  be  used  primarily  as 
guidelines  for  tracking  unit  production  cost  goal  achievement - 
Formats  specifically  for  tracking  operating  and  support  cost  goals  are 
not  provided  because  of  the  very  imited  experience  and  present  wide 
variation  in  the  application  of  the  DTC  concept  to  the  operation  and 
support  (O&S)  area.  It  is,  Viowever,  the  responsibility  of  the  project/ 
program  manager  to  apply  and  track  operating  and  support  cost  goals  to 
the  extent  practicable  on  his  particular  pro ject/program.  It  is 
envisioned  that  a format  similar  to  that  of  Format  B would  be  used  to 
track  and  report  achievement  of  operating  and  supporv.  goals  (i.e., 
operating  crew  requirements,  reliability,  or  maintainability  require- 
ments, spares  cost,  direct  manpower  costs,  etc.).  If  the  CWBS  does  not 
provide  appropriate  breakout  for  tracking  operating  and  support 
goals,  other  identification  such  as  work  unit  code  may  be  used  instead. 

Format  A,  shown  on  page  64,  illustrates  the  DTC  breakdowti  of 
recurring/  nonrecurring  costs  to  provide  a unit  production  cost  goal 
for  each  significant  cost  element  contributing  to  the  total  cost  of  a 
WBS  element.  Prcjact/program  managers  may  identify  and  use  cost 
elements  tailored  to  the  specific  contrac  ■ at  a level  of  detail 
consistent  with  the  dollar  magnitude  and  cost  uncertainty  (risk)  of 
the  program.  Renorting  by  CWBS  may  be  limited  or  expanded  to  provide 
visibility  to  those  defense  system  elements  considered  critical  to  DTC 
goal  achievement.  Use  of  Format  A provides  the  project/program 
manager  a summary  report  of  the  current  DTC  estimates  reported  by  the 


contractor  (£or  the  particular  reporting  period)  as  compared  to  the 
allocated  DTC  goals,  and  any  variance  therefrom,  be  It  favorable  or 
unfavorable.  While  the  Format  A sample  includes  many  of  the  inclusive 
costs,  only  those  that  apply  to  the  individual  contract  goals  would  be 
shown;  for  example,  some  contract  DTC  goals  may  not  include  nonrecurring 
costs. 

Format  B on  page  65  provides  a framework  for  the  contractor  to 
list  those  WBS  elements  from  Format  A for  which  a DTC  variance  exists 
and,  in  a narrative  analysis,  provide  an  explanation  of. the  variance 
from  the  established  DTC  goal,  as  well  as  changes  in  DTC  goal  allo- 
cation, and  differences  between  current  and  previous  DTC  estimates. 

The  project/prograra  manager  may  establish  a threshold  dollar  value  or 
a percentage  of  the  DTC  baseline  which,  when  exceeded  requires  an 
analysis  of  variance.  Further,  the  contractor  should  state  the  impact 
on  other  characteristics/requirements  (i.e.,  technical,  performance, 
schedule,  etc.)  and  describe  any  corrective  action  taken  or  planned. 

Design  to  Cost  information  will  be  forwarded  to  the  Government  at 
the  contractually  agreed  to  dates  and/or  milestones.  Interim  report- 
ing should  be  required  whenever  an  individual  threshold  is  exceeded  or 
if  the  sum  of  the  system  estimated  costs  exceed  the  total  DTC  goal. 

as  stated  above,  DTC  information  is  only  one  element  of  effective 
DTC  project/program  management. Information  requirements  should  be 
determined  in  conjunction  with  the  other  elements  of  the  plan  for 
execution  of  a DTC  program  and  all  of  these  elements  should  be  appro- 
priately reflected  in  conflict  requirements.  The  following  factors 
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should  be  considered  in  determining  DTC  information  requirements: 

- Government  and  contractor  management  responsibilities  for  DTC 
including  those  for  review  and  control  of  DTC  status 

- The  CWBS  Tlements  to  be  tracked  and  reported 

- The  reporting  schedule 

- Requirements  for  contractor  generation  and  use  of  DTC  projections 

- Requirements  for  DOD  access  to  contractor  DTC  data  and  for 
on-site  evaluation  and  verification  of  contractor  DTC  escimates 

- Any  specific  thresholds  for  DTC  reporting  and  variance  analysis 

- Cost/schedule/performance  tradeoff  reporting  requirements  and 
procedures 

- Potential  impact  of  contractor  overhead  costs  on  DTC  goal 
achievement 

- Responsibilities  for  tracking  subcontractor  DTC  status 

- Monitoring  and  control  of  costs  that  may  not  be  included  in 
contract  DTC  goals  (e.g.,  engineering  change  proposals,  cost  of 
peculiar  support  equipment,  cost  of  Covtrnment-furnished  equip- 
ment) 

- Procedures  for  adjustment  of  DTC  goals  for  major  contract 
changes 

- Treatment  of  economic  escalation  in  adjusting  contract  DTC  Roal 
and/or  formulating  cost  esti^iates 
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PTC  Guidelines  for  a KanaRement  Informarlon  Sys tern 

1.  Guideiinej  for  a PTC  reporting  system  consist  of  two  formats 
containing  PTC  and  related  data  for  measuring  performance  toward 
achieving  PTC  goals.  These  data  will  be  used  by  Government  and 
contractor  managers  lo,  (a)  assess  how  effectively  the  contractor  is 
implementing  the  PTC  program;  (b)  evaluate  PTC  goals  and  monitor  their 
achievement;  and  (c)  provide  the  projections  and  ana].ysis  needea  to 
develop  timely  management  decisions  concerning  design  changes  and/or 
tradeoffs. 

2.  A PTC  status  report  is  normally  required  for  contracts  having 
PTC  goals,  Reporting  by  the  Contract  Work  Breakdown  Structure.  fCWBS) 
may  be  limited  or  expanded  to  provide  visibility  to  those  CWBS  ele- 
ments considered  critical  to  PTC  goal  achievement.  Identification  and 
use  of  cost  elements  may  be  tailored  to  the  specific  contract  consis- 
tent witn  the  dollar  magnitude  of  the  program. 

3.  Formats  A and  B represent  sample  reports  that  can  be  used  by 
Project/  Program  Managers  to  track  PTC  performance  against  goals: 

Cost  Element/eWBS  Rata  - cost  goals  in  accordance  with  Format  A 
for  identified  cost  elements  and  contract  work  breakdown  structure 
elements. 

Cost  Variance  Analysis  - prepared  in  accordance  with  Format  B to 
agreed  to  contract  work  breakdown  structure  level.  Variance  analysis 
will  be  required  for  all  elements  which  exceed  the  Government  estab- 
lished threshold, 

NOTE:  Formats  also  may  be  modified  as  necessary  to  adapt  them  for 

tracking  operating  and  support  costs  or  factors  identified  as 
Peslgn  to  Cost  goals. 
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cation,  and  difference  between  current  estimate  and  previous  estimate.  State  impact  on  other  element 
Technical,  Cost,  Perfoirmance,  Schedule,  etc.)  and  provide  a schedule  for  corrective  action  or  specify 
corrective  action  accomplished. 
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